-
Object类所有的非final方法 设计之初都是为了被覆盖的
- 什么时候不应该覆盖equals方法:
- 类的每个实例 理论上都是唯一的 默认的equals已经是正确的了
理解:要判断当前类的是 值 对象还是 行为 对象:- 值:需要提供equals方法判断值相同则对象相同;比如Integer,Double等包装类型;
- 行为:每次生成的对象都是唯一的,比如线程Thread等,此时,不应该覆盖equals方法,每个对象都应该是独一无二的;
- 不用关心是否提供逻辑相等的功能;
以行为为主的对象使用object继承过来的equals足够 - 父类覆盖的equals方法,子类不用重写
集合(Set,List,Map)都已从父抽象类中继承equals,所以不用重写 - 如果类是私有的.为了不让外接调用equals方法,应该在equals方法里面抛出异常
这种情况一般比较少见 - 值类:对象相等就是逻辑相等,比如枚举,和常规类型
- 类的每个实例 理论上都是唯一的 默认的equals已经是正确的了
- 什么时候应该覆盖:
- 父类没有覆盖equals方法
- 类需要拥有逻辑相等的功能,而不是判断是否为同一个对象
跟父类逻辑不同,需要覆盖 - map或者set集合,为了过滤重复的值
- equals方法覆盖的时候 注意的通用准则
- 自反性:x.equals(x)必须返回true 同一个类的同一个对象 应该是相同的;
- 对称性:x.equals(y)和y.equals(x)必须相同
- 传递性: x.equals(y)为true; y.equals(z)为true, 则x.equals(z)也必须为true
- 一致性:x.equals(y)多次调用,返回的值相同
- equals方法使用范例:
- 使用==操作符检查对象引用
- 使用==操作符检查对象是否相同
- 使用instaceof检查参数是否正确,并且在类型转换前进行类型检查
- 什么时候不应该覆盖equals方法:
-
覆盖equals方法的时候必须覆盖hashCode方法
Java是根据equals和hashCode方法来判断对象是否相同 -
始终要覆盖toString方法
方便后期debug调试对象,查看对象各个值是否符合预期; -
谨慎的覆盖Clone
Cloneable是一个mixin接口,表示对象允许clone,但是Object的Clone方法是受保护的,只能借助于反射调用 -
考虑实现comparable接口
类实现了comparable接口,表明具有内在的排序关系
实现之后可以跟许多泛型算法以及依赖于该接口的集合实现进行协作,比如包装类型Integer,Double等都实现了comparable接口,以便于区分大小
EffectiveJava读书笔记第三章 所有对象通用的方法
最后编辑于 ：
©著作权归作者所有,转载或内容合作请联系作者
- 文/潘晓璐 我一进店门，熙熙楼的掌柜王于贵愁眉苦脸地迎上来，“玉大人，你说我怎么就摊上这事。” “怎么了？”我有些...
- 文/花漫 我一把揭开白布。 她就那样静静地躺着，像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上，一...
- 文/苍兰香墨 我猛地睁开眼，长吁一口气：“原来是场噩梦啊……” “哼！你这毒妇竟也来了？” 一声冷哼从身侧响起，我...
推荐阅读更多精彩内容
- Object类的所有非final方法（equals、hashCode、toString、clone、finaliz...
