专业化中的参数类型协方差

tl;博士

在不支持泛型的语言（PHP）中，有哪些策略可以克服特化的参数类型不变性？

注意：我希望我可以说我对类型理论/安全/方差等的理解更完整;我不是CS专业 .

情况

你有一个抽象类， Consumer ，你想要扩展 . Consumer 声明了一个需要定义的抽象方法 consume(Argument $argument) . 应该不是问题 .

问题

您的专业 Consumer ，名为 SpecializedConsumer ，没有逻辑业务可以处理每种类型的 Argument . 相反，它应该接受 SpecializedArgument （及其子类） . 我们的方法签名更改为 consume(SpecializedArgument $argument) .

abstract class Argument { }

class SpecializedArgument extends Argument { }

abstract class Consumer { 
    abstract public function consume(Argument $argument);
}

class SpecializedConsumer extends Consumer {
    public function consume(SpecializedArgument $argument) {
        // i dun goofed.
    }
}

我们正在打破Liskov substitution principle，并导致类型安全问题 . 船尾 .

问题

好的，所以这不会起作用 . 但是，鉴于这种情况，存在哪些模式或策略来克服类型安全问题，以及违反LSP，但仍然保持 SpecializedConsumer 到 Consumer 的类型关系？

我想完全可以接受的是，答案可以被提炼为“ya dun goofed，回到绘图板” .

注意事项，细节和勘误表

• 好吧，一个直接的解决方案表现为“不要在 Consumer 中定义 consume() 方法” . 好吧，这是有道理的，因为方法声明只有签名一样好 . 语义上虽然没有 consume() ，即使有一个未知的参数列表，也会伤害我的大脑 . 也许有更好的方法 .

• 从我_492809看到的涉及generics的创意“解决方案”; PHP中不支持的另一个功能 .

• 来自Wiki的Variance (computer science) - Need for covariant argument types?：

这会在某些情况下产生问题，其中参数类型应该与模拟现实生活要求相协调 . 假设你有一个代表一个人的 class . 一个人可以看医生，所以这个班可能有一个方法虚拟无效Person :: see（医生d） . 现在假设您要创建Person类Child的子类 . 也就是说，孩子是一个人 . 然后，人们可能想要制作医生，儿科医生的子类 . 如果孩子只访问儿科医生，我们希望在类型系统中强制执行 . 然而，一个天真的实现失败：因为一个孩子是一个人，孩子::看（d）必须带任何医生，而不仅仅是儿科医生 .

文章接着说：

在这种情况下，访客模式可用于强制执行此关系 . 在C中解决问题的另一种方法是使用泛型编程 .

同样，generics可以创造性地用于解决问题 . 我正在探索visitor pattern，因为无论如何我都有一个半生不熟的实现，但是文章中描述的大多数实现都利用了方法重载，这是PHP中另一个不受支持的功能 .

<too-much-information>

实施

由于最近的讨论，我忽略了包括（因为，我可能包括太多的方式） .

为了简洁起见，我已经为那些（应该）非常清楚其目的的人排除了方法体 . 我试图保持这个简短，但我倾向于罗嗦 . 我不想转储代码墙，因此解释在代码块之后/之前 . 如果你有编辑权限，并希望清理它，请执行 . 此外，代码块不是项目中的copy-pasta . 如果某些事情没有意义，那可能不会;对我大喊大叫澄清一下 .

关于原始问题，此后 Rule 类是 Consumer 而 Adapter 类是 Argument .

与树相关的类包括如下：

abstract class Rule {
    abstract public function evaluate(Adapter $adapter);
    abstract public function getAdapter(Wrapper $wrapper);
}

abstract class Node {
    protected $rules = [];
    protected $command;
    public function __construct(array $rules, $command) {
        $this->addEachRule($rules);
    }
    public function addRule(Rule $rule) { }
    public function addEachRule(array $rules) { }
    public function setCommand(Command $command) { }
    public function evaluateEachRule(Wrapper $wrapper) {
        // see below
    }
    abstract public function evaluate(Wrapper $wrapper);
}

class InnerNode extends Node {
    protected $nodes = [];
    public function __construct(array $rules, $command, array $nodes) {
        parent::__construct($rules, $command);
        $this->addEachNode($nodes);
    }
    public function addNode(Node $node) { }
    public function addEachNode(array $nodes) { }
    public function evaluateEachNode(Wrapper $wrapper) {
        // see below
    }
    public function evaluate(Wrapper $wrapper) {
        // see below
    }
}

class OuterNode extends Node {
    public function evaluate(Wrapper $wrapper) {
        // see below
    }
}

所以每个 InnerNode 包含 Rule 和 Node 个对象，每个 OuterNode 只包含 Rule 个对象 . Node::evaluate() 将每个 Rule （ Node::evaluateEachRule() ）计算为布尔值 true . 如果每个 Rule 都通过，则 Node 已经过去，它的 Command 被添加到 Wrapper ，并将下降到子项以进行评估（ OuterNode::evaluateEachNode() ），或者只返回 true ，分别用于 InnerNode 和 OuterNode 个对象 .

至于 Wrapper ; Wrapper 对象代理 Request 对象，并具有 Adapter 对象的集合 . Request 对象是HTTP请求的表示 . Adapter 对象是特定用于特定 Rule 对象的专用接口（并维护特定状态） . （这是LSP问题的来源）

Command 对象是一个动作（一个整齐的打包回调，真的），它被添加到 Wrapper 对象，一旦完成所有操作， Command 对象的数组将按顺序触发，传递 Request （以及其他内容） .

class Request { 
    // all teh codez for HTTP stuffs
}

class Wrapper {
    protected $request;
    protected $commands = [];
    protected $adapters = [];
    public function __construct(Request $request) {
        $this->request = $request;
    }
    public function addCommand(Command $command) { }
    public function getEachCommand() { }
    public function adapt(Rule $rule) {
        $type = get_class($rule);
        return isset($this->adapters[$type]) 
            ? $this->adapters[$type]
            : $this->adapters[$type] = $rule->getAdapter($this);
    }
    public function commit(){
        foreach($this->adapters as $adapter) {
            $adapter->commit($this->request);
        }
    }
}

abstract class Adapter {
    protected $wrapper;
    public function __construct(Wrapper $wrapper) {
        $this->wrapper = $wrapper;
    }
    abstract public function commit(Request $request);
}

所以给定的用户土地 Rule 接受预期的用户土地 Adapter . 如果 Adapter 需要有关请求的信息，则会通过 Wrapper 进行路由，以保持原始 Request 的完整性 .

当 Wrapper 聚合 Adapter 对象时，它会将现有实例传递给后续 Rule 对象，以便 Adapter 的状态从一个 Rule 保留到下一个 Rule . 一旦 an entire 树通过，就会调用 Wrapper::commit() ，并且每个聚合的 Adapter 对象将根据需要对原始 Request 应用它的状态 .

然后我们留下一个 Command 对象数组和一个修改过的 Request .

What the hell is the point?

好吧，我不想在许多PHP框架/应用程序中重新创建原型"routing table" common，所以我选择了"routing tree" . 通过允许任意规则，您可以快速创建 AuthRule （例如）到 Node ，并且在不传递 AuthRule 的情况下不再可以访问整个分支 . 在理论上（在我的脑海中），它让我感到困惑和害怕 .

Why I left this wall of nonsense?

好吧，这是我需要修复LSP问题的实现 . 每个 Rule 对应一个 Adapter ，这并不好 . 我想保持每个 Rule 之间的关系，以确保类型安全构建树时，等等，但是我不能抽象地 Rule 声明的主要手段（ evaluate() ），作为亚型的特征变化 .

另一方面，我正在努力整理 Adapter 创建/管理方案;是否由 Rule 负责创建它等 .

</too-much-information>