Liskov 替换原则和 PHP 接口

Question

以下代码是否直接违反了 Liskov 替换原则：
子类不应该破坏父类的类型定义。

class Baz {}
class Foo extends Baz {}

interface a
{
    public function baz(Baz $baz);
}

class b implements a
{
    public function baz(Foo $foo)
    {
    }
}

哪些结果：

致命错误：b::baz(Foo $foo) 的声明必须与 a::baz(Baz $baz) 兼容

Answer 1

您的示例是非法的这一事实不会破坏 LSP。您的问题是正在定义一个接口，并且在实现它时期望遵守该合同。

重要的是要记住，LSP 最终处理的是对象，而不是类。

通过实现接口a，然后尝试使方法签名不兼容，b 类的用户可能会尝试调用b::baz() 并失败，因为a::baz() 的签名需要Baz，而您的b::baz() 上的不兼容实现需要一个实例 Foo。

例如，如果您的建议是合法的，这可能会发生：

$baz = new Baz();

$b = new b();

// since a::baz(Baz) is specified, the class user believes this
// should be possible, but your illegal implementation
// breaks that expectation

$b->baz($baz); // Not accepted!

这根本不会破坏 LSP。

正确实现你的接口a的类仍然可以接受Foo和Baz类的对象，因为可以使用子类型的对象而不是那些超级类型的，正如 LSP 所说的那样。

你不能做的是编写一个签名不兼容的方法，未来的协变和逆变支持也不允许这样做。

---

关于返回类型和参数类型的协变和逆变支持：在 PHP 7.4 中有支持，预计 2019 年底发布。

您可以阅读（已接受）提案here的详细信息。

• 仅返回类型支持协方差（因此，如果父类或接口声明的返回类型为 T，则定义现在可以指定 T 的子类）

• 参数类型将支持逆变（因此，如果父类或接口声明了T 的参数类型，子类或实现类现在可以将T 的超类型声明为参数类型）

在确定方法与其父方法的兼容性时，只要新类型仍接受父方法指定的类型，引擎现在应该允许较少具体的参数类型和更具体的返回类型。换句话说：参数类型可以替换其超类型之一，返回类型可以替换子类型。

同样，这将允许 LSP 支持，并允许类用户能够信任他们正在编程的抽象，而不必检查他们正在使用的具体类的细节。