第十三条、使类和成员的可访问性最小化
设计良好的模块会隐藏所有的实现细节,把它的API和它的实现清晰地隔离开来。然后模块之间只通过它们的API进行通信,一个模块不需要知道其他模块的内部工作情况。(信息隐藏(infomation hiding)和封装(encapsulation))
好处:可以有效地解除组成系统的各模块之间的耦合关系,使得这些模块可以独立地开发、测试、优化、使用、理解和修改。
java的访问机制决定了类、接口和成员的可访问性。实体的可访问性是由该实体声明所在的位置以及访问修饰符共同决定的。对于顶层(非嵌套)的类和接口,只有两种可能的访问级别:包级私有(package-private)和公有的(public),如果用public修饰符声明了顶层类或者接口,那他就是公有的,否则它将是包级私有的。通过把类做成包级私有,它实际上成了这个包的实现部分,而不是该包导出API的一部分。如果一个包级私有的顶层类或者接口只是在某一个类的内部被用到,就应该考虑使它成为唯一使用它的那个类的私有嵌套类。
对于成员(域、方法、嵌套类和嵌套接口)有四种可能的访问级别:
- 私有的private:只有在声明该成员的顶层类内部才可以访问这个成员。
- 包级私有的:声明该成员的包内部的任何类都可以访问这个成员。“缺省default的访问级别”
- 受保护的protected:声明该成员的类的子类可以访问这个成员,且声明该成员的包内部的任何类也可以访问这个成员。受保护的成员是类的导出的API的一部分,必须永远得到支持。导出的类的受保护成员也代表了该类对于某个实现细节的公开承诺,应该尽量少用。
- 公有的public:在任何地方都可以访问。
如果方法覆盖了超类中的一个方法,子类中的访问级别就不允许低于超类中的访问级别。这样可以确保任何可使用超类实例的地方也都可以使用子类的实例。如果一个类实现了一个接口,那么接口中的所有类方法在这个类中也都必须被声明为公有的。(因为接口中所有的方法都隐含着公有访问级别。)
除了公有静态final域的特殊情况之外,公有类都不应该包含公有域,并且要确保公有静态final域所引用的对象都是不可变的。
第十四条、在公有类中使用访问方法而非公有域
应该用包含私有域和公有访问/设置方法的类带进行封装。
第十五条、使可变性最小化
不可变类只是其实例不能被修改的类。每个实例中包含的信息都必须在创建该实例的时候提供,并在对象的整个生命周期内固定不变。(比如:String、基本类型的包装类、BigInteger和BigDecimal)
不可变类的优点:更加易于设计、实现和使用,不容易出错且更加安全。使类成为不可变遵循的五条规则:
- 不要提供任何会修改对象状态的方法(mutator);
- 保证类不会被扩展。
- 使所有的域都是final的。
- 使所有的域都成为私有的。
- 确保对于任何可变组件的互斥访问。
一个类的实例:
/** * Created by laneruan on 2017/6/7. * 这个类表示一个复数。 * 这些算术运算都是创建并返回新的Complex实例,而不是修改这个实例的做法。 * 这种被称为函数的做法,因为这些方法返回恶一个函数的结果,这些函数对操作数进行运算但不修改它。 * 对应的是过程式或命令式的做法。 */ public class Complex { private final double re; private final double im; //对于频繁使用的值,为他们提供公有的的静态常量。 public static final Complex ZERO = new Complex(0,0); public static final Complex ONE = new Complex(1,0); public static final Complex I = new Complex(0,1); public Complex(double re,double im){ this.re = re ; this.im = im ; } //使类变成final的一种方式 // private Complex(double re,double im){ // this.re = re ; // this.im = im ; // } public static Complex valueOf(double re,double im){ return new Complex(re,im); } // Accessors with no corresponding mutators //基于极坐标创建复数 public static Complex valueOfPolar(double r,double theta){ return new Complex(r * Math.cos(theta),r * Math.sin(theta)); } public double realPart(){return re;} public double imaginaryPart(){return im;} public Complex add(Complex c){ return new Complex(re + c.re,im + c.re); } public Complex subtract(Complex c) { return new Complex(re - c.re,im - c.im); } public Complex multiply(Complex c){ return new Complex(re*c.re-im*c.im,re*c.im+im*c.re); } public Complex divide(Complex c){ double tmp = c.re * c.re + c.im * c.im; return new Complex((re*c.re+im*c.im)/tmp,(im*c.re-re*c.im)/tmp); } @Override public boolean equals(Object o) { if(o == this){ return true; } if(!(o instanceof Complex)){ return false; } Complex c = (Complex) o ; return Double.compare(re,c.re) == 0 && Double.compare(im,c.im) == 0; } @Override public int hashCode(){ int result = 17 + hashDouble(re); result = 31 * result + hashDouble(im); return result; } private int hashDouble(double val){ long longBits = Double.doubleToLongBits(val); return (int)(longBits ^ (longBits >>>32)); } @Override public String toString(){ return "(" + re + "+" + im+"i)"; } }
这个类表示一个复数。这些算术运算都是创建并返回新的Complex实例,而不是修改这个实例的做法。这种被称为函数式的做法,因为这些方法返回了一个函数的结果,这些函数对操作数进行运算但不修改它。对应的是过程式或命令式的做法。
这种函数方法的优点带来了不可变性,不可变对象只有一种状态,即被创建时的状态。不可变对象本质上是线程安全的,不要求同步。当多个线程并发访问这样的对象,不会发生破坏,所以不可变对象可以被自由地共享。不可变对象为其他对象提供了大量的构件,如果知道一个复杂对象内部的组件不会改变,要维护它的不变性约束是比较容易的。
不可变类的真正唯一缺点在于:对于每个不同的值都需要一个单独的对象。
如何使不可变类自身不被子类化?除了使类成为final外,让类的所有构造器都变成私有的或者包级私有的,并添加共有的静态工厂来代替公有的构造器。以Complex为例:
private Complex(double re,double im){ this.re = re ; this.im = im ; } public static Complex valueOf(double re,double im){ return new Complex(re,im); }
这种方式虽不常用,但是最灵活。而且可以肯定不能扩展。
有关不可变类的序列化:
实现Serializable接口,并且它包含一个或者多个指向可变对象的域,就必须提供一个显式的readObject或者readResolve方法,或者使用ObjectOutPutStream.writeUnshared和ObjectInputStream.readUnshared方法,即使默认的序列化形式是可接受的。
第十六条、复合优先于继承
- 继承(inheritance)是实现代码重用的有力手段,但是使用不当会导致软件变得很脆弱,在包的内部使用继承是非常安全的,在那里,子类和父类的实现都处在同一个程序员的控制下。然而,对于普通的具体类进行跨越包边界的继承,则是非常危险的。继承打破了封装性,子类依赖于父类中特定功能的实现细节。父类的实现有可能会随着发行版本的不同而有所变化,子类可能随之遭到破坏,因此子类也必须随着父类的更新而演变。
导致子类脆弱的一个相关原因是:它们的父类在后续发行版本中可以获得新的方法。这些问题都来源于覆盖(overriding)动作。下面是一个脆弱的实例:
import java.util.Arrays; import java.util.Collection; import java.util.HashSet; /** * Created by laneruan on 2017/6/7. * 需要查询HashSet。看看自从它从被创建以来曾经添加了多少个元素。 * HashSet类中添加元素的方法:add和addAll,因此这两个方法都要覆盖,但并不能正常工作。 * 因为在HashSet的内部,addAll方法是基于add实现的,所以通过addAll方法增加的每个元素都计算了两次。 * 此时可以通过去掉addAll的覆盖方法来修正这个问题,但是这是十分脆弱的,它的功能正确性是需要依赖于HashSet的addAll方法是在 * add方法上实现的,不能保证随着发行版本的不同而不发生变化。所以此时的InstrumentedHashSet是十分脆弱的。 */ //Broken - Inappropriate use of inheritance public class InstrumentedHashSet<E> extends HashSet<E> { private int addCount = 0 ; public InstrumentedHashSet(){} public InstrumentedHashSet(int initCap,Float loadFactor){ super(initCap,loadFactor); } @Override public boolean add(E e){ addCount ++; return super.add(e); } @Override public boolean addAll(Collection<? extends E> c){ addCount += c.size(); return super.addAll(c); } public int getAddCount(){ return addCount; } public static void main(String[] args){ InstrumentedHashSet<String> s = new InstrumentedHashSet<String>(); s.addAll(Arrays.asList("Snap","Pop","Crackle")); System.out.println(s.getAddCount());//打印出来是6? } }
复合(composition):不用扩展现有的类,而是在新的类中增加一个私有域,它引用现有类的一个实例。因为现有的类变成了新类的一个组件。新类中的每个实例方法都可以调用被包含的现有类实例中对应的方法,并返回它的结果。这被称为转发(forwarding),新类中的方法被称为转发方法。这样新得到的类会非常稳固,不依赖于现有类的实现细节。下面是上面脆弱的实例的复合版本:
import java.util.*; /** * Created by laneruan on 2017/6/8. * Set接口的存在使得InstrumentedSet类的设计成为可能,因为Set类保存了HashSet类的功能特性。 * 从本质上来说这个类把一个Set变成了一个增加计数功能的Set。 * 因为每个InstrumentedSet实例都把另一个Set实例包装起来了,所以称为wrapper class */ //Wrapper class 包装类 public class InstrumentedSet<E> extends ForwardingSet<E>{ private int addCount = 0; public InstrumentedSet(Set<E> s){ super(s); } @Override public boolean add(E e){ addCount++; return super.add(e); } @Override public boolean addAll(Collection<? extends E> c){ addCount += c.size(); return super.addAll(c); } public int getAddCount(){ return addCount; } public static void main(String[] args){ InstrumentedSet<String> s = new InstrumentedSet<String>(new HashSet<String>()); s.addAll(Arrays.asList("Snap","Pop","Crackle")); System.out.println(s.getAddCount());//打印出来是3 System.out.println(s); } } //Reusable forwarding class class ForwardingSet<E> implements Set<E>{ private final Set<E> s; public ForwardingSet(Set<E> s){this.s = s;} @Override public int size() { return s.size(); } @Override public boolean isEmpty() { return s.isEmpty(); } @Override public boolean contains(Object o) { return s.contains(o); } @Override public Iterator<E> iterator() { return s.iterator(); } @Override public Object[] toArray() { return s.toArray(); } @Override public <T> T[] toArray(T[] a) { return s.toArray(a); } @Override public boolean add(E e) { return s.add(e); } @Override public boolean remove(Object o) { return s.remove(o); } @Override public boolean containsAll(Collection<?> c) { return s.containsAll(c); } @Override public boolean addAll(Collection<? extends E> c) { return s.addAll(c); } @Override public boolean retainAll(Collection<?> c) { return s.retainAll(c); } @Override public boolean removeAll(Collection<?> c) { return s.removeAll(c); } @Override public void clear() { s.clear(); } @Override public boolean equals(Object o) { return s.equals(o); } @Override public int hashCode() { return s.hashCode(); } @Override public String toString() { return s.toString(); } }
什么时候使用继承?
只有当子类真正是父类的子类型(subtype)时,即当两者之间确实存在“is-a”关系时,类B才应该扩展A。如果不能确定每个B确实都是A,通常情况下,B应该包含A的一个私有实例,而且暴露一个较小的、较简单的API: A本质上不是B的一部分,只是它的实现细节而已。
第十七条、要么为继承而设计,并提供文档说明,要么就禁止继承
该类的文档必须精确地描述覆盖每个方法所带来的影响,即说明它可覆盖的方法的自用性。
为了继承而设计的类,对这个类会有一些实质性的限制。如:构造器决不能调用可被覆盖的方法。另一种合理的办法是确保这个类永远不会调用它的任何可覆盖的方法。
第十八条、接口优于抽象类
接口和抽象类是Java用来定义允许多个实现的类型的两种机制。
它们之间最明显的区别在于:抽象类允许包含某些方法的实现,但是接口则不允许。一个更为重要的区别在于:为了实现抽象类定义的类型,类必须成为抽象类的一个子类。而任何一个类,只要它定义了所有必要的方法,并且遵守通用约定,它就被允许实现一个接口,而不管这个类是处于类层次的哪个位置。因为Java只允许单继承,不可能有一个以上的父类,所以抽象类作为类型定义受到了极大的限制。
接口的优点:
现有的类很容易被更新,以实现新的接口:如果这些方法尚不存在,你需要做的只是增加必要的方法,然后在类声明中增加一个implements子句。而一般来说,无法更新现有的类来扩展新的抽象类。
接口是定义mixin(混合类型)的理想选择。mixin类型是指:类除了实现它的“基本类型”之外,还可以实现这个mixin类型,以表明它提供了某种可供选择的行为。如Comparable接口,这样的接口之所以被称为mixin,是因为它允许任选的功能可被混合到类型的主要功能中。
接口允许我们构造非层次结构的类型框架。有些事物是不能被整齐地组织成一个严格的层次结构。
通过对你导出的每个重要接口都提供一个抽象的骨架实现类(skeletal implementation),把接口和抽象类的优点结合起来。
接口的作用依然是定义类型,但是骨架实现类接管了所有与接口实现相关的工作。按照惯例,骨架实现类成为AbstractInterface,这里的Interface指实现的接口名。如AbstractCollection、AbstractSet等。如果设计得当,骨架实现可以使程序员很容易提供他们自己的接口实现。
//下面是一个静态工厂方法,它包含一个完整的、功能全面的List实现。 static List<Integer> intArrayAsList(final int[] a){ if(a == null) throw new NullPointerException(); return new AbstractList<Integer>() { @Override public Integer get(int i) { return a[i]; //AutoBoxing } @Override public Integer set(int i,Integer val){ int oldVal = a[i]; a[i] = val; return oldVal; } @Override public int size() { return a.length; } }; }
骨架实现的美妙之处在于:它们为抽象类提供了实现上的帮助,但又不强加“抽象类被用作类型定义时”所特有的严格限制。骨架实现类能够有助于接口的实现,实现了这个接口的类可以把对于接口方法的调用,转发到一个内部私有类的实例上,这个内部私有类扩展了骨架实现类(这就是模拟多重继承)。
编写骨架实现类需要认真地研究接口,首先确定哪些方法是最为基本的,其他的方法可以根据它们来实现。这些基本方法将成为骨架实现类中的抽象方法。然后,必须为接口中的所有其他方法提供具体的实现。下面是一个实例:
import java.util.AbstractList; import java.util.List; import java.util.Map; /** * Created by laneruan on 2017/6/8. */ public abstract class AbstractMapEntry<K,V> implements Map.Entry<K,V> { public abstract K getKey(); public abstract V getValue(); @Override public V setValue(V value) { throw new UnsupportedOperationException(); } @Override public boolean equals(Object o){ if(o == this) return true; if(!(o instanceof Map.Entry)) return false; Map.Entry<?,?> arg = (Map.Entry) o ; return equals(getKey(),arg.getKey()) && equals(getValue(),arg.getValue()); } public static boolean equals(Object o1,Object o2){ return o1 == null ? o2 == null : o1.equals(o2); } @Override public int hashCode(){ return hashCode(getKey()) ^ hashCode(getValue()); } public static int hashCode(Object obj){ return obj == null ? 0 : obj.hashCode(); } }
抽象类与使用接口相比有一个明显的优势:
抽象类的演变比接口的演变要容易得多。如果在后续的发行版本中,你希望在抽象类中增加新方法,始终可以增加具体的包含合理的默认实现的方法。而接口是行不通的。因此,设计公有的接口要非常谨慎,接口一旦被公开发行,并且已经被广泛实现,再想改这个接口几乎是不可能的。
总结:
接口通常是定义允许多个实现类型的最佳途径,这条规则有个例外,即当演变的容易性比灵活性和功能更为重要的时候。在这种情况下,应该使用抽象类来定义类型,前提是必须理解和可以接受这些局限性。
如果你导出一个重要的接口,就应该坚决考虑同时提供骨架实现类。最后应该尽可能谨慎地设计所有的公有接口,并通过编写多个实现来对它们进行全面的测试。
第十九条、接口只用于定义类型
当类实现接口时,接口就充当可以引用这个类的实例的类型(type),因此,类实现了接口就表明客户端可以对这个类的实例实施某种动作。
为了任何其他目的而定义接口是不恰当的,比如常量接口,这种接口没有包含任何方法,只包含静态的final域,每个域都导出一个常量。
第二十条、类层次优于标签类
tagged class 标签类:带有两种甚至更多种风格的实例的类,并包含表示实例风格的标签(tag)域。这种标签类有着许多缺点,过于冗长、容易出错且效率低。
子类型化(sub typing),变成类层次。它们可以用来反映类型之间本质上的层次关系,有助于增强灵活性,并进行更好的编译时类型检查。
第二十一条、用函数对象表示策略
- 有些语言支持函数指针(function pointer)、代理(delegate)、lambda表达式,或者支持类似的机制,允许程序把“调用特殊函数的能力”存储起来并传递这种能力。这种机制通常用于允许函数的调用者通过传入第二个函数来指定自己的行为。
class StringLengthComparator{ public int compare(String s1,String s2){ return s1.length() - s2.length(); } }
调用对象上的方法通常是执行该对象上的某项操作。然而,我们也可能定义这样一种对象,它的方法执行其他对象上这些对象被显式传递给这些方法上的操作。如果一个类仅仅导出这样的一个方法,它的实例实际上就等同于一个指向该方法的指针。这样的实例被称为函数对象(function object)。
作为典型的具体策略类,StringLengthComparator类是无状态的(stateless):没有域。所以这个类的所有实例在功能上都是等价,作为Singleton是非常合适的。指向StringLengthComparator对象的引用可以被当做是一个指向该比较器的函数指针,可以在任意一对字符串上被调用。即StringLengthComparator实例是用于字符串比较操作的具体策略。
我们在设计具体的策略类时,还需要定义一个策略接口,具体的策略类往往使用匿名类声明。需要注意的是,以匿名类的方法,每次执行都会创建一个新的实例。
class StringLengthComparator implements Comparator<String>{ public int compare(String s1,String s2){ return s1.length() - s2.length(); } } public interface Comparator<T>{ public int compare(T t1,T t2); } Arrays.sort(stringArray,new Comparator<String>(){ public int compare(String s1,String s2){ return s1.length() - s2.length(); } });
- 总结:
在Java中实现这种策略模式,需要声明一个接口来表示这个策略,并且为每个具体策略声明一个实现了该接口的类。当一个具体的策略只被使用一次时,通常使用匿名类来声明和实例化这个具体策略类。当一个具体策略是设计用来重复使用的时候,它的类通常就要被实现为私有的静态成员类,并通过公有的静态final域被导出,其类型为该策略接口。
第二十二条、优先考虑静态成员类
嵌套类(nested class)是指被定义在一个类内部的类。存在的目的应该只是为了外围类提供服务。
嵌套类有四种:静态成员类、非静态成员类、匿名类和局部类。除了第一种类,其他三种都被称为内部类(inner class)静态成员类是最简单的一种嵌套类,它可以访问外围类的所有成员,它遵守同样的可访问性规则。
一种常见的用法是作为公有的辅助类。如果声明成员类不要求访问外围实例,就要始终把static修饰符放在它的声明中。如果不?每个实例都将包含一个额外的指向外围对象的引用,耗时又占空间。
非静态成员类的每个实例都隐含着与外围类的一个实例相关:
如果嵌套类的实例可以在它的外围类实例之外独立存在,则必须是静态成员类。
当非静态成员类的实例被创建的时候,它和外围实例之间的关联也随之被建立起来,而且这种关联关系以后不能被修改。
非静态成员类的一种常见用法是定义一个Adapter,它允许外部类的实例被看作是另一个不相关的类的实例。匿名类不与其他的成员一起被声明和实例化,只有在使用的同时被声明和实例化。可以出现在任何允许存在表达式的地方。
匿名类的常见用法:动态地创建函数对象、创建过程对象(如Runable、Thread等实例)和在静态工厂方法的内部。
局部类用的最少。在任何可以声明局部变量的地方都可以声明局部类。
总结:
四种嵌套类有各自的用途:
如果一个嵌套类需要在单个方法之外依然是可见的、或者太长,就应该使用成员类。
如果成员类的每个实例都需要一个指向其外围实例的引用,就要把成员类做成非静态,否则就是静态的。假设这个嵌套类属于一个方法的内部.
如果你只需要在一个地方创建实例,并且已经有了一个预置的类型可以说明这个类的特征,就把它做成匿名类,否则就是局部类。