第10项:重写equals时请遵守通用约定
重写equals方法看起来似乎很简单,但是有许多重写方式会导致错误,而且后果非常严重。最容易避免这类问题的办法就是不覆盖equals方法,在这种情况下,类的每个实例都只能与它自身相等。如果满足了以下任何一个条件,那就是正确的做法:
类的每个实例都是唯一的。 对于代表活动实体而不是值(value)的类来说确实如此,例如Thread。Object提供的equals实现对这些类具有完全正确的行为(The equals implementation provided by Object has exactly the right behavior for these classes)。
不关心类是否提供了“逻辑相等(logical equality)”的测试功能。 例如,java.util.regex.Pattern可以重写equals检查两个Pattern实例是否表示完全相同的正则表达式,但设计者并不认为客户端需要或想要此功能。 在这种情况下,从Object继承的equals实现是理想的方式。
超类已经重写了equals,从超类继承过来的行为对于子类也是合适的。 例如,大多数的Set实现都从AbstractSet继承equals实现,List实现从AbstractList继承equals实现,Map实现从AbstractMap继承equals实现。
类是私有的或者是包级私有的,可以确定它的equals方法永远不会被调用。 如果你非常讨厌风险,你可以重写equals方法,从而确保它不会被意外调用:
@Override public boolean equals(Object o) {
throw new AssertionError(); // Method is never called
}
那么什么时候重写equals方法才是合适的呢?当一个类具有逻辑相等的概念时(不同于对象本身相同的概念),而超类还没有重写equals。 这通常是“值类(value class)”的情况。 值类指的是只表示值的类,例如Integer或String。程序猿在利用equals方法来比较对象的引用时,希望知道它们在逻辑上是否相等,而不是像了解它们是否引用了相同的对象。为了满足程序猿的需求,不仅必须重写equals方法,而且这样做也使得这个类的实例可以被用作映射表(map)的键(key),或者集合(set)的元素,使映射或者集合表现出预期的行为。
有一种“值类”不需要重写equals方法,即用实例受控(第1项)确保“每个值之多只存在一个对象”的类【单例模式】。枚举类型(第34项)就属于这种类。对于这样的类而言,逻辑相同与对象等同是一回事,因此Object的equals方法等同于逻辑意义上的equals方法。
当你重写equals方法的时候,你一定要遵守它的通用约定。下面是约定的内容,来自Object的规范:
- 自反性(Reflexive):对于任何非null的引用值x,x.equals(x)必须返回true。
- 对称性(Symmetric):对于任何非null的引用值x和y,当且仅当y.equals(x)返回true时,x.equals(y)必须返回true。
- 传递性(Transitive):对于任何非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。
除非你对数学特别感兴趣,否则这些规定看起来可能有点让人感到恐惧,但是绝对不要忽视这些规定!如果你违反了它们,就会发现你的程序表现不正常,甚至崩溃,而且很难阻止失败的根源(and it can be very difficult to pin down the source of the failure)。引用John Donne的话说,没有哪个类是孤立的。一个类的实例通常会被频繁地传递给另一个类的实例。有许多类,包括所有的集合类(collections classes)在内,都依赖于传递给它们的对象是否遵守了equals约定。
现在你已经知道了违反equals约定有多么可怕,现在我们就来更细致地讨论这些约定。值得欣慰的是,这些约定虽然看起来很吓人,实际上并不复杂。一旦你理解了这些约定,要遵守它们并不困难。
那么什么是等价关系呢?大致来说,它是一个运算符,它将一组元素分成子集,这些子集的元素被认为是彼此相等的。这些子集称为等价类。 要使equals方法有用,每个等价类中的所有元素必须可以从用户的角度进行互换。现在我们依次检查一下5个要求:
自反性(Reflexivity)————第一个要求仅仅说明对象必须等于其自身。很难想象会无意识地违反这一条。假如违背了这一条,然后把该类的实例添加到集合(collection)中,该集合的contains方法将会告诉你,该集合不包含你刚才添加的实例。
对称性(Symmetry)————第二个要求是说,任何两个对象对于“他们是否相等”的问题都必须保持一致。与第一个要求不同,若无意中违反第一条,这种情形倒是不难想象。例如,考虑下面的类,它实现了一个区分大小写的字符串。字符串由toString保存,但在比较操作中被忽略:
// Broken - violates symmetry!
public final class CaseInsensitiveString {
private final String s;
public CaseInsensitiveString(String s) {
this.s = Objects.requireNonNull(s);
}
// Broken - violates symmetry!
@Override public boolean equals(Object o) {
if (o instanceof CaseInsensitiveString)
return s.equalsIgnoreCase(((CaseInsensitiveString) o).s);
if (o instanceof String) // One-way interoperability!
return s.equalsIgnoreCase((String) o);
return false;
}
... // Remainder omitted
}
在这个类中,equals方法的意图非常好,它企图与普通的字符串(String)对象进行互操作。假设我们有一个不区分大小写的字符串和一个普通的字符串:
CaseInsensitiveString cis = new CaseInsensitiveString("Polish");
String s = "polish";
正如所料,cis.equals(s)
返回true。问题在于,虽然CaseInsensitiveString类中的equals方法知道普通的字符串(String)对象,但是String类中的equals方法却并不知道不区分大小写的字符串。因此,s.equals(cis)
返回false,显然违反了对称性。假设你把不区分大小写的字符串对象放到一个集合中:
List<CaseInsensitiveString> list = new ArrayList<>();
list.add(cis);
此时list.contains(s)会返回什么结果呢?谁能知道?在当前OpenJDK的实现中,它碰巧返回的是false,但这只是这个特定实现得出的结果而已。在其他的视线中,它有可能返回true,或者抛出一个运行时异常。一旦你违反了equals约定,当其他对象面对你的对象的时候,你完全不知道这些对象的行为会怎么样。
为了解决这个问题,只需要把企图与String互操作的这段代码从equals中去掉就可以了。这样做以后,就可以重构该方法,使它变成一条单独的返回语句:
@Override public boolean equals(Object o) {
return o instanceof CaseInsensitiveString && ((CaseInsensitiveString) o).s.equalsIgnoreCase(s);
}
传递性————equals约定的第三个要求是,如果第一个对象等于第二个对象,并且第二个对象等于第三个对象,则第一个对象一定等于第三个对象。同样地,无意识地违反这条规则的情形也不难想象。考虑子类的情形,它将一个新的值组件(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方法会怎么样呢?如果完全不提供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 - violates transitivity!
@Override public boolean equals(Object o) {
if (!(o instanceof Point))
return false;
// If o is a normal Point, do a color-blind comparison
if (!(o instanceof ColorPoint))
return o.equals(this);
// o is a ColorPoint; do a full comparison
return super.equals(o) && ((ColorPoint) 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)
和pe.equals(p3)
都是返回true,但是p1.equals(p3)
则返回false,很显然违反了传递性。前两种比较不考虑颜色信息(“色盲”),而第三种比较则考虑了颜色信息。
同样,这种方法可以导致无限递归:假设有两个Point的子类,叫做ColorPoint和SmellPoint,每一个子类都使用这种equals方法,那么调用myColorPoint。equals(mySmellPonit)将会抛出一个堆栈溢出的异常(StackOverflowError)。
那么怎么解决呢?这是面向对象语言中关于等价关系的一个基本问题。我们无法在扩展可实例化的类的同事,既增加新的值组件,同时又保留equals约定,除非愿意放弃面向对象的抽象所带来的优势。
你可能听说,在equals方法中用getClass测试代替instanceof测试,可以扩展可实例化的类和增加新的值组件,同时保留equals约定:
// Broken - violates Liskov substitution principle (page 43)
@Override public boolean equals(Object o) {
if (o == null || o.getClass() != getClass())
return false;
Point p = (Point) o;
return p.x == x && p.y == y;
}
这段程序只有当对象具有相同的实现时,才能使对象等同。虽然这样也不算太糟糕,但是结果却是无法接受的:Point子类的一个实例仍然是一个Point,它仍然需要作为一个函数运行,但是如果采用这种方法它就不能这样做! 让我们假设我们想要写一个方法来判断一个点是否在单位圆上。 这是我们可以做到的一种方式:
// Initialize unitCircle to contain all Points on the unit circle
private static final Set<Point> unitCircle = Set.of(
new Point( 1, 0), new Point( 0, 1),
new Point(-1, 0), 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 static int numberCreated() { return counter.get(); }
}
里氏替换原则(Liskov substitution principle)认为,一个类型的任何重要属性也将适用于它的子类型,因此为该类型编写的任何方法,在它的子类型上也应该同样运行得很好[Liskov87]。这是我们早期的正式声明,即Ponit(如CounterPoint)的子类仍然是Point,并且必须作为一个Point来工作。但是假设我们将CounterPoint传递给onUnitCircle方法。 如果Point类使用基于getClass的equals方法,则无论CounterPoint实例的x和y坐标如何,onUnitCircle方法都将返回false。之所以如此,是因为像onUnitCircle方法所用的是HashSet这样的集合,利用equals方法检验包含条件【即在Set集合中插入对象的时候会先检查该对象是否已存在】,没有任何CounterPonit实例与任何Point实例对应。但是,如果在Point上使用适当的基于instanceof的equals方法,当遇到CounterPoint时,相同的onUnitCircle方法就可以正常工作。
虽然没有一种令人满意的办法可以即扩展不可实例化的类,又增加值组件,但还是有一种不错的权宜之计(workaround):根据第18项的建议:组合优先于继承。我们不再让ColorPoint扩展Point,而是在ColorPoint中加入一个私有的Point字段,以及一个公有的视图(view)方法(第6项),此方法返回一个与该有色点处在相同位置的普通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) {
point = new Point(x, y);
this.color = Objects.requireNonNull(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 = (ColorPoint) o;
return cp.point.equals(point) && cp.color.equals(color);
}
... // Remainder omitted
}
在Java平台类库中,有一些类扩展了可实例化的类,并添加了新的值组件。例如,java.sql.Timestamp对java.util.Date进行了扩展,并增加了nanoseconds字段。Timestamp的equals实现却是违反了对称性,如果Timestamp和Date对象被用于同一个集合中,或者以其他方式被混合在一起,则会引起不正确的行为。Timestamp类有一个免责声明,告诫程序猿不要混合使用Date和Timestamp对象。只要你不把它们混合在一起,就不会有麻烦,除此之外没有其他的措施可以防止你这么做,而且结果导致的错误将很难调试。Timestamp类的这种行为是个错误,不值得效仿。
注意,你可以在一个抽象(abstrace)类的子类中增加新的值组件,而不会违反equals约定。这对于类层次结构很重要,您可以通过遵循第23项中的建议“用类层次(class hierarchies)代替标签类(tagged classes)”来获得类层次结构。例如,你可能有一个抽象的Shap类,它没有任何值组件,Circle子类添加了一个radius字段,Rectangle子类添加了length和width字段。只要不可能直接创建超类的实例,前面所述的种种问题就都不会发生。
一致性(Consistency)————equals约定的第四个要求是,如果两个对象相等,他们就必须始终保持相等,除非它们中有一个(或者两个都)被修改了。换句话说,可变对象在不同的时候可以与不同的对象相等,而不可变对象则不会这样。当你在写一个类的时候,应该仔细考虑清楚它是否应该是不可变的(第17项)。如果认为它应该是不可变的,就必须保证equals方法满足这样的限制条件:相等的对象永远相等,不相等的对象永远不相等。
无论类是否是不可变的,都不要使equals方法依赖于不可靠的资源。如果你违反了这个禁令,就很难满足一致性要求。例如,java.net.URL的equals方法依赖于对URL中主机IP地址的比较。将一个主机名转变成IP地址可能需要访问网络,随着时间的推移,不确保会产生相同的结果。这样会导致URL的equals方法违反equals约定,在实践中有可能引发一些问题。URL中equals方法的这种行为是一个很大的错误,而且不应该被效仿。遗憾的是,因为兼容性的要求,这一行为无法被改变。为了避免这种问题,equals方法应该只对驻留在内存的对象执行确定性计算。
非空性(Non-nullity)————最后一个要求没有名称,我姑且称它为“非空性(Non-nullity)”。意思是指所有对象都必须不等于null。虽然很难想象在调用o.equals(null)时偶然返回true,但不难想象会不小心抛出NullPointerException。通用约定是禁止这样做的。许多类的equals方法都通过一个显示的null测试来防止这种情况:
@Override public boolean equals(Object o) {
if (o == null)
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的第一个运算对象(operand)是null,那么,不管第二个操作对象(operand)是哪种类型,instanceof操作符都会返回false[JLS, 15.20.2],因此,如果把null传递给equals方法,类型检查就会返回false,所以不需要单独的null检查。
结合所有这些要求,得出了以下实现高质量equals方法的诀窍:
- 使用==操作符检查“参数是否为这个对象的引用”。 如果是,则返回true。这只不过是一种性能优化,如果比较操作有可能很昂贵,就值得这么做。
- 使用instanceof操作符检查“参数是否为正确的类型”。 如果不是,则返回false,一般来说,所谓的“正确的类型”是指equals方法所在的那个类。有些情况下,它是指该类所实现的某个接口。如果类实现的接口改进了equals约定,允许在实现了该接口的类之间进行比较,那么就使用接口。集合接口(collection interfaces)如Set、List、Map和Map.Entry具有这样的特性。
- 把参数转换成正确的类型。 因为转换之前进行过instanceof测试,所以确保会成功。
- 对于该类中的每个“关键(significant)”字段,检查参数中的字段是否与该对象中对应的字段相匹配。 如果这些测试全部成功,则返回true,否则返回false。如果第2步中的类型是个借口,就必须通过接口方法访问参数中的字段;如果该类型是类,也许就能够直接访问参数中的字段,这就要取决于它们的可访问性。
对于既不是float类型也不是double类型的基本类型字段,可以使用==
操作符进行比较;对于对象引用类型的字段,可以递归地调用equals方法;对于float字段,可以使用静态方法Float.compare(float, float)
方法进行比较;对于double字段,使用Double.compare(double,double)
。对float和double字段进行特殊的处理是有必要的,因为存在着Float.NaN、-0.0f以及类似的double常量;详细信息请参考JLS 15.21.1或者Float.equals的文档。虽然你可以使用静态方法Float.equals和Double.equals来比较float和double字段,但是这会在每次比较时产生自动装箱,这会导致性能不佳。 对于数组字段,请将这些指导原则应用于每个元素。 如果数组字段中的每个元素都很重要,请使用Arrays.equals方法中的其中一个方法进行比较。
有些对象引用类型的字段包含null可能是合法的,所有,为了避免可能导致的NullPointerException异常,使用静态方法Objects.equals(Object, Object)
来检查这些字段是否相等。
对于有些类,例如CaseInsensitiveString类,字段的比较要比简单的相等性测试复杂得多。如果是这种情况,可能会希望保存该字段的一个“范式(canonical form)”,这样equals方法就可以根据这些范式进行低开销的精确比较,而不是高开销的非精确比较。这种方法对于不可变类(第17项)是最为合适的;如果对象可能发生变化,就必须保证其范式保持最新。
字段的比较顺序可能会影响到equals方法的性能。为了获得最佳的性能,你应该最先比较最有可能不一致的字段,或者是开销最低的字段,最理想的情况是两个条件同时满足的字段。你不应该去比较那些不属于对象逻辑状态的字段,例如用于同步操作的Lock字段。您不需要去比较那些可以从关键字段计算出来的派生字段(derived fields),但是这样做【比较派生字段】有可能提高equals方法的性能。如果派生字段代表了整个对象的综合描述,比较这个字段可以节省当比较失败时去比较实际数据所需要的开销【也就是说当(条件一)派生对象可以代表两个对象是否相等的时候,同时(条件二)比较这个派生字段的开销比比较实际数据的开销小的情况下,我们可以使用派生字段进行对象是否相等的比较】。例如,假设有一个Polygon类,并缓存了该区域。如果两个多边形【Polygon的实例】有着不同的区域,就没有必要去比较他们的边和至高点。
- 当你编写完equals方法之后,应该问你自己三个问题:它是否具有对称性?是否具有传递性?是否具有一致性? 并且不要只是自问,还要编写单元测试来检验这些特性,除非你使用AutoValue【谷歌的一个开源框架,下面有提到】(原文49页)自动生成equals方法,在这种情况下,您可以安全地忽略测试。如果属性无法保持,找出原因,并相应地修改equals方法。当然,你的equals方法也必须满足另外两个属性(自反性和非空性),但这两个一般是相通的(If the properties fail to hold, figure out why, and modify the equals method accordingly. Of course your equals method must also satisfy the other two properties (reflexivity and non-nullity), but these two usually take care of themselves)。
在这个简单的PhoneNumber类中显示了根据前面的诀窍构造的equals方法:
// Class with a typical equals method
public final class PhoneNumber {
private final short areaCode, prefix, lineNum;
public PhoneNumber(int areaCode, int prefix, int lineNum) {
this.areaCode = rangeCheck(areaCode, 999, "area code");
this.prefix = rangeCheck(prefix, 999, "prefix");
this.lineNum = rangeCheck(lineNum, 9999, "line num");
}
private static short rangeCheck(int val, int max, String arg) {
if (val < 0 || val > max)
throw new IllegalArgumentException(arg + ": " + val);
return (short) val;
}
@Override public boolean equals(Object o) {
if (o == this)
return true;
if (!(o instanceof PhoneNumber))
return false;
PhoneNumber pn = (PhoneNumber)o;
return pn.lineNum == lineNum && pn.prefix == prefix && pn.areaCode == areaCode;
}
... // Remainder omitted
}
下面是最后的一些说明:
- 重写equals方法时总要重写hashCode方法(第11项)。
- 不要企图让equals方法过于智能。 如果只是简单地测试域中的值是否相等,则不难做到遵守equals约定。如果想过度地去寻求各种等价关系,则很容易陷入麻烦之中。把任何任何一种别名形式考虑到等价的范围内,往往是一个坏主意。例如,File类不应该试图把指向同一个文件的符号链接(symbolic link)当做相等的对象来看待。所幸File类没有这样做。
- 不要将equals声明中的Object对象替换为其他的类型。 程序猿编写出下面这样的equals方法并不少见,这会使程序猿花上数小时都搞不清为什么它不能正常工作:
// Broken - parameter type must be Object!
public boolean equals(MyClass o) {
...
}
问题在于,这个方法并没有重写Object.equals方法,因为它的参数应该是Object类型,相反,它重载了Object.equals(第52项)。在原有equals方法的基础上,再提供一个“强类型(strongly typed)”的equals方法,这是无法接受的,因为它可能导致子类中的Override注释产生误报并提供错误的安全感(because it can cause Override annotations in subclasses to generate false positives and provide a false sense of security)【可能会导致子类中的Override注释在编译的时候报错】。
Override注释的用法一致,就如本项中所示,可以防止犯这种错误(第40项)。这个equals方法不能编译,错误消息将会告诉你到底哪里出了问题:
// Still broken, but won’t compile
@Override public boolean equals(MyClass o) {
...
}
编写和测试equals(和hashCode)方法很繁琐,结果代码很平常。 手动编写和测试这些方法的一个很好的替代方法是使用Google的开源AutoValue框架,该框架会自动为您生成这些方法,由类中的单个注释触发。 在大多数情况下,AutoValue生成的方法与您自己编写的方法基本相同。
IDE也有生成equals和hashCode方法的工具,但结果源代码比使用AutoValue的代码更冗长,更不易读,不会自动跟踪类中的更改,因此需要测试。 也就是说,让IDE生成equals(和hashCode)方法通常比手动实现它们更可取,因为IDE不会造成粗心的错误,人类也会这样做。
总之,不要重写equals方法,除非您不得不这么做:在许多情况下,从Object继承的实现完全符合您的要求。 如果你确实重写了equals,请确保比较所有类的关键字段,并使用之前提到的五个诀窍对它进行测试(If you do override equals, make sure to compare all of the class’s significant fields and to compare them in a manner that preserves all five provisions of the equals contract)。
第10项:重写equals时请遵守通用约定的更多相关文章
- 第8条:覆盖equals时请遵守通用约定
第8条:覆盖equals时请遵守通用约定 引言:尽管Object是一个具体类,但是设计它主要是为了拓展.它所有的非final方法(equals.hashCode.toString.clone和fina ...
- 第八条:覆盖equals时请遵守通用约定
==是物理相等 equals是逻辑相等 因为每个类的实例对象本质上都是唯一的 ,利用物理相等(==)是指一个实例只能相等于它自己. 利用逻辑相等是(equals)指 一个实例是否和另一个实例的某些关键 ...
- Item 8 覆盖equals时请遵守通用约定
在覆盖equals方法的时候,你必须要遵守它的通用约定,不遵守,写出来的方法,会出现逻辑错误.下面是约定的内容: equals方法实现了等价关系: 自反性.对于任何非null的引用值,x.eq ...
- 覆盖equals时请遵守通用约定
Object类中非final修饰的方法有equals().hashCode().toString().finalize().clone()1.equals()方法不需要被覆盖的情况:1)实例化的对象只 ...
- 【Effective Java】4、覆盖equals时请遵守通用约定
package cn.xf.cp.ch02.item8.transitivity; public class Point { private final int x; private final in ...
- 覆盖equals方法时请遵守通用约定
覆盖equals方法时请遵守通用约定 覆盖equals方法看起来很简单,但是有许多覆盖方式会导致错误,并且后果很严重.最容易避免这种类问题的方法就是不覆盖equals方法,在这种情况下,类的每个实 ...
- 重写equals时,遵守的规定
0 正确的equals方法 public class MyClass { // 主要属性1 private int primaryAttr1; // 主要属性2 private int prima ...
- Effective Java 第三版——10. 重写equals方法时遵守通用约定
Tips <Effective Java, Third Edition>一书英文版已经出版,这本书的第二版想必很多人都读过,号称Java四大名著之一,不过第二版2009年出版,到现在已经将 ...
- 第8条:覆盖equals时遵守通用约定
如果不需要覆盖equals方法,那么就无需担心覆盖equals方法导致的错误. 什么时候不需要覆盖equals方法? 1.类的每个实例本质上是唯一的. 例如对于Thread,Object提供的equa ...
随机推荐
- try(){}自动释放资源,AutoCloseable
我们在使用资源的时候,必须关闭资源,比如使用jdbc连接或者inputStream的时候,必须在finally中将资源关闭.然而有的时候我们会忘记关闭资源.那么有没有更好的方法呢? SqlSessio ...
- 前端黑魔法:webworker动态化,无需JS文件创建worker
前言 前几天,我和一位知乎网友讨论这个问题的时候,觉得这非常有意思,所以写了这篇文章作为记录 本文的思路和项目代码来源于知友 @simon3000,我加以修饰以更符合理解的需求. 本文所用代码已经 ...
- Servlet接口的实现
Servlet接口对Servlet进行了规范,定义了方法的主要范围. 1.public void init(ServletConfig servletConfig) (初始化) 参数的作用: (1)调 ...
- 一文搞懂 deconvolution、transposed convolution、sub-pixel or fractional convolution
目录 写在前面 什么是deconvolution convolution过程 transposed convolution过程 transposed convolution的计算 整除的情况 不整除的 ...
- 即时聊天APP(六) - 消息的接收以及EventBus使用
通常我们在接收消息的时候会有声音和震动的提示,因此我也加了代码达到这样的效果,这就要用到EventBus了,当然这里我也用到了自定义的广播,所以首先在Mainfests文件中加入以下代码: <r ...
- 小白专场-是否同一颗二叉搜索树-python语言实现
目录 一.二叉搜索树的相同判断 二.问题引入 三.举例分析 四.方法探讨 4.1 中序遍历 4.2 层序遍历 4.3 先序遍历 4.4 后序遍历 五.总结 六.代码实现 一.二叉搜索树的相同判断 二叉 ...
- 轻松部署calico
一.资源 官方文档 https://docs.projectcalico.org/v3.8/getting-started/kubernetes/installation/integration 二. ...
- Scrapy项目 - 数据简析 - 实现斗鱼直播网站信息爬取的爬虫设计
一.数据分析截图(weka数据分析截图 2-3个图,作业文字描述) 本次将所爬取的数据信息,如:房间数,直播类别和人气,导入Weka 3.7工具进行数据分析.有关本次的数据分析详情详见下图所示: ...
- 【求赐教】VMware workstation 转VSphere
首先我从其他电脑拷贝过来一台虚拟机(这个说法不知道准不准确,就是把所有文件夹都拷贝过来了),然后打开VMware,通过"打开虚拟机"这个操作,直接找到本地的.vmx文件,如下图所示 ...
- Spring MVC-从零开始-@RequestMapping结合@RequestParam (从HTTP键值对中取值,作用于函数参数)
1.@RequestParam 注解使用的时候可以有一个值,也可以没有值:如果请求参数和处理方法参数的名称一样的话,@RequestParam 注解的 value 这个参数就可省掉了:@Request ...