一种扩展可实例化类并添加值组件的方法，同时保留equals契约

Question

Joshua Blotch的《有效Java》中写道：

除非您愿意放弃面向对象抽象的好处，否则在保留等于契约的同时，无法扩展可实例化类并添加值组件。

有效Java给出了一些例子，这些例子要么破坏了对称性、传递性，要么破坏了Liskov替换原理<我想你已经读过了。我觉得我不应该把整个项目都贴在这里

点：

public class Point{
    private final int x;
    private final int y;
    public Point(int x, int y){
        this.x = x;
        this.y = y;
    }
    protected boolean equalsImpl(Point p){
        return p.x == x && p.y == y;
    }
    @Override
    public final boolean equals(Object o) {
        if(!(o instanceof Point))
            return false;
        Point p = (Point)o;
        return equalsImpl(p) && p.equalsImpl(this);
    }
    // Remainder omitted ...
}

ColPoint：

public class ColorPoint extends Point{
    private java.awt.Color color;
    public ColorPoint(int x, int y, java.awt.Color color){
        super(x, y);
        this.color = color;
    }
    @Override
    protected boolean equalsImpl(Point p){
        return (p instanceof ColorPoint) &&
                super.equalsImpl(p) &&
                ((ColorPoint)p).color == color;
    }
    // Remainder omitted ...
}

我知道在这种情况下应该使用合成，但是我想知道我的解决方案是否真的遵守equals契约。如果是，有效Java的陈述是错误的吗？




Answer 1

我想知道什么是LSP，所以我偶然发现了一篇好文章。正如文章所说，Liskov Substution原则不适用于Java

LSP对属性集定义了一个弱约束，但随后声称，对于任何属性，都可以证明程序行为是相同的。唯一可以验证这一点的方法是，如果系统中的原始对象由其规范严格定义，以至于它们不允许其他实现。例如，上述论文的作者声称，给定一个方法的一组属性，他们可以声称与另一个具有相同契约的方法在行为上100%兼容——但这不是真的。本质上，我可以说Java中toString（）方法的约定非常弱——“返回对象的字符串表示”。

为什么Liskov替换原则很重要？

1. 因为如果不这样做，那么类层次结构将是一团糟。混乱的是，每当子类实例作为参数传递给任何方法时，都会发生奇怪的行为。
2. 因为如果没有，超类的单元测试将永远不会成功。

参考链接，可能会澄清您的疑问。

Answer 2

equals合约不需要LSP。

也许这个问题是因为在等于实现的主题中不必要地包含了LSP。eclipse生成的标准equals实现已经使用了super。等于（利用继承），并且比建议的解决方案更正确、更简单。然而，它不符合LSP的标准，根据文件，LSP是可以的。

Answer 3

匿名用户

在这种实现中，任何色点都不等于点，因此它违反了Liskov替换原则。不过，它确实尊重与同等的合同。

更新：LSP是否被破坏取决于Point类具有的契约。如果您有一个契约说“具有相同X和Y坐标的两个点相等”或“您可以使用HashSet来消除具有重复坐标的点”，它就被破坏了。如果不存在这样的合同，LSP就不会违约。

另一方面，如果没有色点等于点，那么色点是-a点有意义吗？