effective java(8) 之覆盖equals时遵守通用的约定

xiaoxiao2021-02-28  5

effective java 之覆盖equals时遵守通用的约定 1、覆盖equals方法看起来很简单,但是有许多覆盖方式会导致错误,并且后果很严重。 最容易避免这种类问题的方法就是不覆盖equals方法,在这种情况下,类的每个实例都只能与它自己相等。 如果满足了一下任何一个条件,这都是所谓期望的结果: 类的每个实例的本质上都是唯一的。 对于代表活动实体而不是值的类来说确实如此,例如Thread。Object提供的equals实现对于这些类来说正是正确的行为。 不关心类是否提供了“逻辑相等”的测试功能。 例如java.util.Random覆盖了equals,以检查两个Random实例是否产生相同的随机数序列,但是设计者并不认为客户端需要或者期望这样的功能。 在这样的情况下,从Object继承得到的equals实现已经足够了。 超类已经覆盖了equals,从超类继承过来的行为对于子类也是合适的。 例如大多数的Set实现都是从AbstractSet继承equals实现,List实现从AbstractList继承equals实现,Map实现从AbstractMap继承equals实现。 类是私有的或是包级私有的,可以确定他的equals方法永远不会被调用。 在这种情况下无意识应该覆盖equals方法的,以防止它被意外调用: @Overrid public boolean equals(Object o){ throw new AssertionError();//Method is never called } 2、什么时候应该覆盖Object.equals 如果类具有自己特有的“逻辑相等”概念(不同于对象等同的概念),而且超类还没有覆盖equals以实现期望的行为,这时我们需要覆盖equals方法。这通常属于“值类”的情形。 值类仅仅只是一个表示值的类,例如Integer或者Date。 程序员在利用equals方法来比较值对象的引用时,希望知道他们在逻辑上是否相等,而不是想了解他们是否是一个对象。 为了满足程序员的要求,不仅必须覆盖equals方法,而且这样做也使得这个类的实例可以被用作映射表(map)的键(key),或者集合(set)的元素,使映射或者集合表现出预期的行为。 3、有一种“值类”比较特殊,不需要覆盖equals方法,即用实例受控确保“每个值之多只存在一个对象”的类。枚举类型就属于这种类。 对于这种类,逻辑相同与对象相同是一回事,因此Object的equals方法等同于逻辑意义上的equals方法。 4、在覆盖equals方法时,你必须要遵守他的通用约定。 equals方法实现了等价关系(equivalence relation): 自反性(reflexive)。对于任何非空的引用值x,x.equals(x)必须返回true。 对称性(symmetric)。对于任何非空的引用值x和y,当且仅当y.equals(x)返回true时,x.equals(y)必须返回true。 传递性(reansitive)。对于任何非null的引用值x、y和z,如果x.equals(y)返回true,并且y.equals(z)也返回true,那么x.equals(z)也必须返回true。 一致性(consistent)。对于任何非null的引用值x和y,只要equals的比较操作在对象中所用的信息没有被修改,多次调用x.equals(y)就会一致的返回true,或者一致的返回false。 对于任何非null得引用值x,x.equals(null)必须返回false。 如果你违反了它们,就会发现你的程序将会表现不正常,甚至崩溃,而且很难找到失败的根源。没有哪个类是孤立的。 一个类通常会被频繁地传递给另一个类的实例。有许多类,包括所有的集合类(collection class)在内,都依赖于传递给他们的对象是否遵守equals约定。 5、自反性: 第一个要求仅仅说明对象必须等于自身。很难想象会无意识的违反这一条。 假如违反这一条,然后把该类的实例添加到集合中,该集合的cantains方法将果断告诉你,该集合不包含你刚刚添加的实例。 6、对称性: 任何两个对象对于“他们是否相等”的问题都必须保持一致。 与第一个要求不同,若无意识的违反这一条,这种情形倒是不难想象。假如,考虑下面的类,它实现了一个区分大小写的字符串。字符串由toString保存,但在比较操作中被忽略。 //Broken - violates symmetry public final class CaseInsensitiveString { private final String s; public CaseInsensitiveString(String s) throws NullPoinerException { if (s == null) { throw new NullPoinerException(); } this.s = s; } // Broken - violates symmetry @Override public boolean equals(Object o) { if (o instanceof CaseInsensitiveString) return s.equalsIgnoreCase(((CaseInsensitiveString) o).s); if (o instanceof String) return s.equalsIgnoreCase((String) o); return false; } public static void main(String[] args) throws NullPoinerException { CaseInsensitiveString cis = new CaseInsensitiveString("Polish"); String s = "Polish"; System.out.println("cis=s:" + cis.equals(s)); System.out.println("s=cis:" + s.equals(cis)); /*cis=s:true s=cis:false*/ } } 正如所视,cis.equals(s)返回true。 问题在于,虽然CaseInsensitiveString类中的equals方法知道普通的字符串对象, 但是,String类中的equals方法却并不知道区分大小写的字符串。因此,s.equals(cis)返回false,显然违背了对称性。 假设把不区分大小写的字符串对象放入一个集合中: List<CaseInsensitiveString> list = new ArrayList<CaseInsensitiveString>(); list.add(cis); list.contains(s)会返回什么样的结果呢? 在Sun的当前实现中,它碰巧返回false,但这只是这个特定的实现得出的结果而已。 在其他的实现中,它有可能返回true,或者抛出一个运行时异常。 一旦违反了equals约定,当其它对象面对你的对象时,你完全不知道这些对象的行为是什么样。 为了解决这个问题,只需把企图与String互操作的这段代码从equals方法中去掉就可以了。 这样做之后,就可以重构该方法,使它变成一条单独的返回语句: @Override public boolean equals(Object o) { return o instanceof CaseInsensitiveString && ((CaseInsensitiveString) o).s.equalsIgnoreCase(s); } 6、 传递性 如果一个对象等于第二的对象,并且第二个对象等于第三个对象,则第一个对象一定等于第三个对象。 同样的,无意识地违反这条规则的情形也不难理解。考虑子类的情形,它将一个新的值组件(value component)添加到了超类中。 换句话说,子类增加的信息会影响到equals的比较结果。我们首先以一个简单的不可变的二位整数型Point类为开始: public class Point { private final int x; private final int y; public Point(int x,int y){ this.x = x; this.y = y; } @Override public boolean equals(Object o) { if(!(o instanceof Point)) return false; Point p = (Point) o; return p.x == x && p.y == y; } ... //Remainder omitted } 假设我们想要扩展这个类,为一个点添加颜色信息: public class ColorPoint extends Point { private final Color color; public ColorPoint(int x, int y,Color color) { super(x, y); this.color = color; } ... //Remainder omitted } 如果完全不提供equals方法,而是直接从Point继承过来,在equals做比较的时候颜色信息就会被忽略掉。虽然这样做不会违反equals约定,但是很明显这是无法接受的。 假设我们再编写一个equals方法,只有当它的参数是另一个有色点,并且具有同样的位置和颜色时他才会返回true: // Broken - violates symmetry @Override public boolean equals(Object o) { if(!(o instanceof ColorPoint)) return false; return super.equals(o) && ((ColorPoint) o).color == color; } 这个方法的问题在于,你在比较普通点和有色点,以及相反的情形时,可能会得到不同的结果。前一种比较忽略了颜色信息,而后一种则总是返回false,因为参数类型的不正确。为了直观的说明问题所在,我们创建一个普通点和一个有色点: Point p = new Point(1,2); ColorPoint cp = new ColorPoint(1,2,Color.RED); p.equals(cp)返回true,cp.equals(p)则返回false。你可以做这样的尝试来修正这个问题,让ColorPoint.equals在进行“混合比较”时忽略颜色信息: //Broken - violastes transitivity @Override public boolean equals(Object o){ if(!(o instanceof Point)) return false; //If o is normal Point, do a color-blind comparison if(!(o instanceof ColorPoint)) return o.equals(this); return super.equals(o) && ((ClolorPiont) o).color = color; } 这种方法确实提供了对称性,但是却牺牲掉了传递性: ColorPoint p1 = new ColorPoint(1,2,Color.RED); Point p2 = new Point(1,2); ColorPoint p3 = new ColorPoint(1,2,Color.BLUE); 此时,p1.equals(p2)和p2.equals(p3)都是返回true,但是p1.equals(p3)则返回false,很显然违反了传递性。前两种比较不考虑颜色(“色盲”),而第三种比较考虑颜色信息。 事实上,这是面向对象语言中关于等价关系的一个基本问题。 我们无法在扩展可实例化的类的同时,既增加新的值组件,同时又保留equals约定,除非愿意放弃面向对象的抽象所带来的优势。 你可能听说,在equals方法中用getClass测试代替instanceof测试,可以扩展可实例化的类和增加新的值组件,同时保留equals约定: //Broken - voilates Liskov substitution orinciple @Override public boolean equlas(Object o){ if(o == null || o.getClass() != getClass()) return false; Point p = (Point)o; return p.x == x && p.y == y; } 这段程序只有当对象具体的实现时餐能是对象等同。虽然这样也不算太糟糕,但是结果也是无法让人接受的。 假设我们要编写一个方法,以检验某个值点是否在单位圆中。下面是可以采用的其中一种方法: //Initialize UnitCircle to contain all Points on the unit circle private static final Set<Point> unitCircle; static{ unitCircle = new HashSet<Point>(); unitCircle.add(new Point(1,0)); unitCircle.add(new Point(0,1)); unitCircle.add(new Point(-1,0)); unitCircle.add(new Point(0,1)); } public static boolean onUnitCircle(Point p){ return unitCircle.contains(p); } 虽然这可能不是实现这种功能的最快方式,不过它的效果很好。但是假设你通过某种不添加值组件方式扩展了Point,例如让他的构造器记录创建了多少个实例: public class CounterPoint extends Point{ private static final AtomicInteger counter = new AtomicInteger(); public CounterPoint(int x,int y){ super(x,y); counter.incrementAndGet(); } public int numberCreate(){ return counter.get(); } } 里氏替换原则(Liskov substitution principle)认为,一个类型的任何重要属性也将适用于它的子类型,因此为该类型编写的任何方法,在它的子类型上也应该同样运行得很好。 但是假设我们将CounterPoint实例传给了onUnitCircle方法。如果Point类使用了基于getClass的equals方法,无论CounterPoint实例的x和y值是什么,onUnitCircle方法都会返回false。 之所以如此,是因为像onUnitCircle方法所使用的HashSet这样的集合,利用equals方法检验包含条件,没有任何CounterPoint实例与任何Point对应。 但是,如果Point上使用适当的基于instanceof的equals方法,当遇到CounterPoint时,相同的onUnitCircle方法就会工作的很好。 虽然没有一种令人满意的方法可以既扩展不可实例化的类,又增加值组件,但是还是有一种不错的权衡之计。 复合优于继承。我们不再让ColorPoint扩展Poin,而是ColorPoint中加入一个私有的Point域,以及一个公有的视图(view)方法,此方法返回一个于该有色点处在相同位置的普通Point对象: //Adds a value component without violating the equals contract public class ColorPoint{ private final Point point; private final Color color; public ColorPoint(int x,int y,Color color){ if(null == color){ throw new NullPointerException(); point = new Point(x,y); this.color = color; } /** *Returns the point-view of this color point */ public Point asPoint(){ return point; } @Override public boolean equals(Object o){ if(!(o instanceof ColorPoint)){ return false; ColorPoint cp = (ColorPonit)o; return cp.point.equals(point) && cp.color.equals(color); } ... //Remainder omitted } 在Java平台类库中,有一些类扩展了可实例化的类并添加了新的值组件。 例如,java.sql.Timestamp对java.util.Date进行了扩展,并增加了nanoseconds域。Timestemp的equals实现确实违反了对称性,如果Timestamp和Date对象被用于同一个集合中,或者以其他方式被混合在一起,则会引起不正确的行为。Timestamp类有一个免责声明,告诫程序员不要混合使用Date和Timestamp对象。只要你不把它们混合使用就不会有麻烦,除此之外没有其他的措施可你防止你这么做,而且结果到会的错误将很难调试。 7、 一致性 如果两个对象相等,它们就必须始终保持相等,除非它们之中有一个对象(或者两个都)被修改了。 换句话说,可变对象在不同的时候可以与不同的对象相等,而不变的对象则不会这样。 当你写一个类的时候,应该仔细考虑它是否应该是不可变的。如果认为它应该是不可变的,就必须保证equals方法满足这样的限制条件:相等的对象永远相等,不相等的对象永远不相等。 无论类是否是不可变的,都不要使equals方法依赖于不可靠的资源。 如果违反了这条禁令,要满足一致性的要求就十分困难了。例如,java.net.URL的equals方法依赖于对URL中主机IP地址的比较。 将一个主机名转变成IP地址可能需要访问网络,随着时间的推移,不确保会产生相同的结果。这样会导致URL的equals方法违反equals约定,在实践中有可能引发一些问题。 8、非空性 是指所有的对象都必须不等于null。 尽管很难想象什么情况下o.equals(null)的调用会意外地返回true,但是意外抛出的NullPointerException异常的情形却不难想像。 通常约定不允许抛出NullPointerException异常。许多类的equals方法通常都通过一个显示的null测试来防止这种情况: @Override public boolean equals(Object o){ if(null == o) return false; ... } 这项测试是不必要的,为了测试其他参数的等同性,equals方法必须先把参数转换成适当的类型,以便可以使用它的访问方法(accessor),或者访问它的域。在进行转换之前,equals方法必须使用instanceof操作符,检查其参数是否为正确的类型: @Override public boolean equals(Object o){ if(!(o instanceof MyType)) return false; MyType mt = (MyType) o; ... } 如果漏掉了这一步的检查类型,并且传递给equals方法的参数又是错误的类型,那么equals方法将会抛出ClassCastException异常,这就违反了equals的约定。但是,如果instanceof的第一个操作数为null,那么不用管第二个操作数是哪种类型,instanceof操作符都应该返回false。因此,如果把null传给equals方法,类型检查就会返回false,所以不用单独的null检查。 9、结合所有这些要求,得出了一下实现高质量的equals方法的诀窍: 1.使用==操作符检查“参数是否为这个对象的引用”。 如果是,则返回true。这只不过是一种性能优化,如果比较操作符有科恩个很昂贵,就不值得这样做。 2.使用instanceof操作符检查“参数是否为正确的类型”。 如果不是,则返回false。一般来说,所谓“正确的类型”是指equals方法所在的那个类。有些情况下,是指该类所实现的某个接口。如果类实现的接口改进了equals约定,允许在实现了该接口类之间进行比较,那么就是用接口。集合接口(collection instanface)如Set、List、Map和Map.Entry具有这样的特性。 3.把参数转换成正确的类型。 因为转换之前进行过interfaceof测试,所以保证会成功。 4.对于该类的每个“关键(significant)”域,检查参数中的域是否与该对象中对应的域相拼配。 如果这些测试全部成功,则返回true;否侧返回false。如果第2步中的类型是个接口,就必须通过接口方法访问参数中的域;如果该类型是个类,也许就能够直接访问参数中的域,这要取决于它们的可访问性。 对于既不能float也不是double类型的基本数据类型域,可以使用==操作符进行比较;对于对象引用域,可以递归的调用equals方法;对于float域,可以使用Float.compare方法;对于double域,则使用Double.compare。对于float和double域进行特殊处理是很有必要的,因为存在着Float.NaN、-0.0f以及类似的double常量;详细信息请参考Float.equals的文档。对于数组域,则要把以上这些指导原则应用到每个元素上。如果数组域中的每个元素都很重要,就可以使用发行版本1.5中新增的其中一个Arrays.equals方法。 有些对象引用域包含null可能是合法的,所以,为了避免可能导致NullpointerException异常,则使用下面的习惯用法来比较这样的域: (field == null ? o.field == null : field.equals(o.field)) 如果field和o.field通常是相同的对象引用,那么下面的做法就会更快一些: (field == o.field || (field != null && field.equals(o.field))) 对于有些类,比如前面提的CaseInsensitiveString类,域的比较要比简单的等同性测试要复杂的多。如果是这种情况,可能会希望保存该域的一个“范式(canonical form)”,这样equals方法就可以根据这些范式进行低开销的精确比较,而不是高开小的非精确比较。这种方法对于不可变类是最为合适的;如果对象可能发生变化,就必须使其范式保持最新。 域的比较顺序可能会影响到equals方法的心梗。为了获得最佳的性能,应该最先比较最有可能不一致的域,或者是开销最低的域,最理想的情况是两个条件同时满足的域。你不应该去比较那些不属于对象逻辑状态的域,例如用于同步操作的Lock域。也不需要比较冗余域(redundant field),因为这些冗余域可以由“关键域”计算获得,但是这样做有可能提高equals方法的性能。如果冗余域代表了整个对象的综合描述,比较这个域可以节省当比较失败时去比较实际数据所需要的开销。例如假设有一个Polygon类,并缓存了该区域。如果两个多边形有着不同的区域,就没有必要去比价它们的边和至高点。 5.当你编写完成了equals方法之后,应该问自己三个问题:他们是否对称的、传递的、一致的? 并且不要只是自问,还要编写单元测试来检验这些特性!如果答案是否定的,就要找出原因,再相应的修改equals方法的代码。当然equals方法也必须满足其他的两个特性(自反性和非空性),但是这两种特性通常会自动满足。 10、下面是最后的一些告诫: 覆盖equals时总要覆盖hashCode。 不要企图让equals方法过于智能。如果只是简单地测试域中的值是否相等,则不难做到遵守equals约定。如果想过度去寻求各种等价关系,则很容易陷入麻烦之中。 不要把equals声明中的Object对象替换为其他的类型。程序员编写出下面这样的equals方法并不鲜见,这会使程序员花上数个小时都搞不清楚她为什么不能正常工作: public boolean equals(MyClass o){ ... } 问题在于,这个方法并没有覆盖Object.equals,因为他的参数因该是Object类型,相反它重载了(Overload) 了Objec.equals。在原有equals方法的基础上,再提供了一个“强类型(strongly typed)”的equals方法,只要这两个方法返回相同的结果(没有强制的理由这样做),那么这就是可以接受的。在某种特定情况下,它也许能够稍微改善性能,但是与增加的复杂性相比,这种做法是不值的。 @Override注解的用法一致,可以防止这种错误。这个equals不能够编译,错误信息就会告诉你到底哪里出现了问题。 每天努力一点,每天都在进步。
转载请注明原文地址: https://www.6miu.com/read-1100139.html

最新回复(0)