《Effective Java》读书笔记，移动安全入门

时间：2022-12-07 21:30:00 omron钮型传感器r88d

equals()实现等价关系的方法。

自反性。对于任何非null的引用值x，x.equals(x)必须返回true.(对象必须等于自己)
对称性。对于任何非null引用值x和y，当且仅当y.equals(x)返回true时，x.equals(y)必须返回true。(警惕子类父类不同equals实现时）
传递性。对于任何非null的引用只x、y和z，如果x.equals(y)返回true，并且y.equals(z)也返回true，那么x.equeals(z)也必须返回true。（优先使用组合而不是继承，可以避免违反传递性对称性，否则没有完美的解决方案。只要超类不能直接创建实例，就不会违反原则)
一致性。对于任何非null引用值x和y，只要equals对象中使用的比较操作信息未修改，多次调用x.equals(y)返回值一致。
非空性。对于任何非null的引用值x，x.equals(null)必须返回false。(不需要重复判空，只需要使用instance 即可）

实现高质量equals方法的诀窍：

使用==操作符 检查参数是否被引用。如果是，返回true。这是一种性能优化，适的性能优化。
使用instanceof操作符检查参数是否正确。如果没有，返回false。
把参数强转正确的类型。
这一类中的每个关键域匹配比较。（float使用Float.compare()比较，double使用Double.compare()比较。有些filed可能为null,且合法。可以用 (field ==null? o.field==null: field.equals(0.field)) 。如果field和o.field通常引用相同的对象，所以以下做法更快： ( field == o.field || field!=null && field.equlas(0.field))）
编写完equals方法完成后，应进行测试对称性、传递性、一致性。
覆盖equals同时覆盖hashCode。
不要将equals()方法声明中的Object对象替换为其他类型。(public boolean equals(MyClass o)){})

//一个示例

@Override

public boolean equals(Object o) {

if (o == this) {

return true;

}

if (!(o instanceof EnumSingletonTest)) {

return false;

}

EnumSingletonTest data = (EnumSingletonTest) o;

return data.xxx == xxx

&& dta.bbb == bbb;

}

9 覆盖equals时总要覆盖 hashCode

不覆盖这种方法会导致这种方法无法合作HashMap、HashSet和Hashtable一起使用。

因为equals()相等的话，hashCode()必须相等。

一个好的散列函数通常倾向于为不相等的对象产生不相等的散列码”。

10 始终要覆盖 toString

11 谨慎地覆盖clone

一般，x.clone() != x ,x.clone().getClass() == x.getClass(), x.clone().equals(x) (但也不强求)

实际上，clone方法就是另一个结构器；您必须确保它不会伤害原始对象，并确保克隆对象中的约束条件正确创建。

更好的办法是类似集合类那样，提供 转换构造器和转换工厂。并且可以转换构造器和工厂带接口类型的参数。比如你有一个HashSet，想得到TreeSet，clone该方法不能提供这样的功能，但很容易使用转换结构。 new TreeSet(s)。

专家程序员不建议使用clone。

12 考虑实现 Comparable 接口

实现compareTo()方法。它的约定和equals类似的方法。(自反、传输、对称)，但不需要类型检查。顺序很重要，首先更重要的是，如果产生非零结果，则结束比较。

小于返回负整数，等于返回0，大于返回正整数。

墙裂建议，(x.compareTo(y)==0) == (x.equals(y))

用于TreeSet TreeMap，以及工具类Collections、Arrays，内部包含搜索和排序算法。

若未实现一个域Comparable接口，或使用非标准的排序关系。可以使用Comparator替换，或使用现有的Comparator。例如：

public final class A implements Comparable{

private String s ;

public int compareto(A a){

return String.CASE_INSENSITIVE_ORDER_.compare(s,a.s);

}

有时可以直接使用 this.s - other.s 作为返回值，但要保证最小和最大可能域值之间的差异小于或等于INTEGER.MAX_VALUE。否则，计算结果过int型溢出时，结果会相反。

第四章类和接口

使类和成员的可访问性最小化

隐藏内部数据和实现细节。

尽可能使每个类别或成员不被外界访问。

对于顶层(非嵌套)只有类和接口两种可能的访问级别：私有私有(缺省) 和公有的。

如果是包级私有顶层活接口只是在某一个类的内部被用到，就应该考虑使他成为那个类的私有嵌套类。

然而，比上一点更重要的是降低不必要的共同类别的可访问性。

成员依次有：private、包级私有（default）、protected(只能访问子类和包内)，public

protected应少用，和public都作为公开API的一部分。

若该方法涵盖了超类中的一种方法，子类中的访问级别就不允许低于超类中的访问级别。这样可以保证子类也可以在任何可以使用超类的地方使用。

实例域绝不能公有。如果域是非final如果是这样，那就更不合适了。如果是这样的话。如果是这样的话。final该域包含可变对象的引用，可以修改引用对象，导致灾难性后果。

非零长度的数组总是可变的。类有公共静态final几乎总是错误的数组域的访问方法，几乎总是错误的。因为客户端可以修改数组中的内容，这是一个安全漏洞。

有两种方法可以纠正这个问题：

同时，访问权限为私有增加公共不可变列表。

private static final A[] PRIVATE_VALUES = {…};

public static final List VALUES =

Collections.unmdifiableList(Arrays.asList(PRIVATE_VALUES ));

访问权限设为私有，增加一个公有方法，返回私有数组的一个备份：

private static final A[] PRIVATE_VALUES = {…};

public static final A[] values(){

return PRIVATE_VALUES .clone();

}

14 在公有类中使用访问方法而非公有域

如果类可以在它所在的包的外部进行访问，就提供访问方法。

如果类是包级私有的，或者是私有的嵌套类，直接暴漏它的数据域并没有本质的错误。

公有类永远都不应该暴露可变的域。偶尔会暴漏不可变域。

有时候会暴露包级私有的或者私有的嵌套类的域，无论这个类可变还是不可变。

15 使可变性最小化

不可变类只是其实例不能被修改的类。

每个实例中包含的所有信息都必须在创建该实例的时候就提供，并在对象的整个生命周期内固定不变。例如String、基本类型的包装类、BigInteger、BigDecimal。

不可变类遵循下面五条规则：

不要提供任何会修改对象状态的方法（改变对象属性的方法）。
保证类不会被扩展。（final或者私有、包级私有构造器，提供公有静态工厂）
使所有的域都是final的。
使所有的域都成为私有的。
确保对于任何可变组件的互斥访问。确保客户端无法获取指向可变对象的域的引用。并且永远不要用客户端提供的对象引用来初始化这样的域，也不要从任何访问方法中返回该对象的引用。

大多数不可变类在修改域时，都是通过返回一个新的对象做的。只对操作数进行运算但不修改它。

这被成为 函数的 functional做法，与之对应的是过程的procedural 或者命令式的 imperative，这些方式会导致状态改变。

例如

public class ImmutableExampleTest {

private final int value;

public ImmutableExampleTest(int value) {

this.value = value;

}

public int getValue() {

return value;

}

public ImmutableExampleTest add(ImmutableExampleTest b) {

return new ImmutableExampleTest(value + b.value);

}

不可变对象可以只有一种状态，即被创建时的状态。

不可变对象本质上是线程安全的，它们不要求同步。

不可变对象可以被自由地共享。鼓励客户端尽可能地重用现有的实例。可以对频繁用到的值，提供公有的静态final常量。

不可变对象永远不需要保护性拷贝。不应该提供clone方法或者拷贝构造器。

不仅可以共享不可变对象，甚至也可以共享它们的内部信息。例如BigInteger类的negate()方法，返回的BigInteger对象中的数组指向原始实例中的同一个内部数组。

不可变对象为其他对象提供了大量的构件（building blocks）。

不强求所有的域都是final的，但必须保证：没有一个方法能够对对象的状态产生 外部可见 的改变。可以用非final域去缓存一些昂贵开销的计算的结果（配合lazy initialization）。

如果不可变类实现了Serializable接口，并且包含一个或多个指向可变对象的域，需要特殊处理。

不可变对象真正唯一的缺点是，对于每个不同的值都需要一个单独的对象。

如果你执行一个多步骤的操作，并且每个步骤都会产生一个新的对象，除了最后的结果之外其他的对象最终都会被丢弃，此时性能问题就会暴露出来。两种解决办法：

先猜测一下经常用到哪些多步骤操作，然后将它们作为基本类型提供。
如果无法预测，最好的办法就是提供一个公有的可变配套类。String类是不可变类，它的可变配套类是StringBuilder。BigInteger对应BigSet。

总结：

尽量将小的值对象，成为不可变的。认真考虑将较大的值对象做成不可变的，例如String、BigInteger。只有当性能确实需要优化时，才为不可变的类提供公有的可变配套类。

如果类不能被做成不可变的，仍然应该尽可能地限制它的可变性。除非有令人信服的理由，否则每个域都是final的

不应该提供“重新初始化”方法，它会增加复杂性。

16 复合优先于继承（组合大于继承）

继承是实现代码重用的有力手段，但它并非永远是最佳工具。

在包内部使用继承非常安全，因为它属于同一个程序员的控制之下。

对于专门为继承而设计、并具有很好的文档说明的类，继承也非常安全。

（这里的继承代表实现继承，指的是一个类继承另一个类。对于类实现接口、或者接口继承接口都不属于这种情况）

与方法调用不同的是，继承打破了封装性。

子类依赖于其超类中特定功能的实现细节。超类的实现有可能随着发行版本的不同而有所变化，如果发生了变化，子类可能遭到破坏，即使子类的代码完全没有改变。

只有当子类和超类之间确实存在 “is-a”关系时，才应该用继承。

继承机制会把超类API中的所有缺陷传播到子类中，而复合（装饰、代理）则允许设计新的API 来隐藏这些缺陷。

17 要么为继承而设计，并提供文档说明，要么就禁止继承。

构造器决不能调用可被覆盖的方法。不管是直接的还是间接的调用。

如果类是为了继承而被设计的，无论实现Cloneable或Serializable都不是好主意。因为它把一些实质性的负担转嫁给扩展这个类的程序员的身上。因为**clone()或readObject()方法行为上类似于构造器，所以也不可以调用可覆盖的方法，不管以直接还是间接的形式。**

如果必须从这种类继承，一种办法是确保这个类永远不会调用它的任何可覆盖的方法。

18 接口优于抽象类

现有的类可以很容易被更新，以实现新的接口。

接口是定义mixin（混合类型）的理想选择。

接口允许我们构造非层次（竖向）结构的类型框架。

虽然接口不允许包含方法的实现。**但通过对每个重要接口都提供一个抽象的骨架实现（skeletal implementation）类，把接口和抽象类的优点结合起来。**接口的作用仍然是定义类型，但是骨架实现类接管了所有与接口实现相关的工作。

按照惯例，骨架实现类称为AbstractInterface，例如AbstractCollection、AbstractSet等。

骨架实现上有个小小的不同，就是简单实现。AbstractMap.SimpleEntry就是个例子，简单实现类似于骨架实现类，因为它实现了接口，并且也是为了继承而设计的，区别在于它不是抽象的：它是最简单的可能的有效实现。你可以原封不动地使用，也可以看情况将它子类化。

抽象类比接口有一个明显的优势：抽象类的演变比接口的演变要容易的多。

如果在后续的版本中，希望在抽象类中增加新的方法，始终可以增加具体方法，包含合理的默认实现即可。

一般来说，想在公有接口中增加方法，而不破坏实现这个接口的所有现有的类，这是不可能的。可以通过在为接口增加新方法的同时，也为骨架实现类增加同样的新方法，来一定程度上减小破坏。

因此，一个接口一旦公开发行，再修改基本不可能。

总结：

接口通常是定义允许多个实现（多态）的最佳途径。

如果你想要演变的容易性比功能、灵活性更重要，而且你接受抽象类的局限性，就用抽象类。

接口->骨架实现类->简单实现类。

19 接口只用于定义类型

除此之外，为了任何其他的目的而定义接口是不恰当的。

说白了，定义接口是为了接口的行为。

有一种接口是常量接口，这是对接口的不良使用。因为常量是实现细节，不应该泄漏出去。对类的用户来说没有价值，反而会干扰。而且如果非final类实现了常量接口，它的所有子类的命名空间也会被接口中的常量所“污染”。

定义常量应该用枚举或者不可实例化的工具类。

20 类层次优于 标签类

想到了自己项目里群聊创建模块。原本就是一个标签类，改造成了类层次。

类层次好处：

简单清晰，没有样板代码，不受无关数据域的拖累，多个程序员可独立扩展层次结构。而且类层次可以反映类型之间本质上的层次关系，有助于增强灵活性。

标签类有很多缺点：

可读性差
内存占用增加因为实例承担着属于其他风格的不相关的域。
域不能是final的。

总之它过于冗长，容易出错，效率低下。

其实标签类是对类层次的一种简单的效仿。

将标签类转化成类层次：

为标签类的每个方法都定义一个包含抽象方法的抽象类，这里的每个方法的行为都依赖于标签值。
如果有行为不依赖于标签值的方法，就将这些方法放在抽象类里。
如果所有的方法都用到了某些域，则将域也放在抽象类里。
为每种原始标签书写相应的子类。

21 用函数对象表示策略

如果一个类，它只有一个方法，这个方法执行其他对象（通过参数传入）上的操作。

这个类的实例实际上等同于一个指向该方法的指针。

这样的实例称之为函数对象。也是一个具体策略类。

我们在设计具体的策略类时，还需要定义一个策略接口。

总结：函数指针的主要用途就是实现策略模式。

为了在java中实现这个模式，要声明一个接口来表示该策略，并且为每个具体策略实现该接口。

当具体策略只使用一次时，通常用匿名内部类来做。

当重复使用时，通常实现为某个类私有的静态成员类，并通过公有静态 final 域被导出，域类型是策略接口类型。

22 优先考虑静态成员类

嵌套类指定义在另一个类内部的类。目的是只为它的外围类服务。

如果嵌套类将来可能用于其他的环境中，它就应该是顶层类。

嵌套类四种:

静态成员类（优先）
非静态成员类
匿名类（不能拥有静态成员，如果只有一处创建的地方）
局部类（有多处创建的地方）

后三种被称为内部类。

静态成员类是最简单的一种嵌套类，最好把它看作是普通的类，只是碰巧被声明在另一个类的内部而已。

如果声明内部类不要求访问外围实例，就要声明称静态成员类。

内部类会包含一个额外的指向外围对象的引用，保存这份引用要消耗时间和空间，也会影响GC.

匿名类的常见用法：

动态创建函数对象。（21条）
创建过程对象，比如Runnable、Thread。
静态工厂方法的内部。

第五章泛型

出错之后应该尽快发现，最好是在编译时就发现。

23 请不要在新代码中使用原生态类型、

List对应的原生态类型就是List,如果使用原生态类型，就丢掉了泛型在安全性和表述性方面的所有优势。它只是为了兼容遗留代码的。

无限制的通配符类型：List，等于List,它们和List

《Effective Java》读书笔记，移动安全入门

20 类层次优于标签类

相关文章