【Java与模式】接口、抽象类

一、Java语言的接口

1.1 什么是接口

一个Java接口是一些方法特征的集合，这些方法特征当然来自于具体方法，但是它们一般都是来自于一些在系统中不断出现的方法。一个接口只有方法的特征，而没有方法的实现，因此这些方法在不同的地方被实现时，可以具有完全不同的行为。在Java语言中，Java接口还可以定义public的常量。

在Java语言规范中，一个方法的特征仅包括方法的名字、参量的数目和种类、而不包括方法的返还类型、参量的名字以及所抛出的异常。在Java编译检查方法的重载时，会根据这些条件判断两个方法是否是重载方法。但是在Java编译器检查方法的置换时，则会进一步检查两个方法（分处超类型和子类型）的返还类型和抛出异常是否相同。

一个类实现一个接口，这种关系叫做接口继承，而一个类是另一个类的子类，这种关系叫做实现继承，接口继承的规则与实现继承的规则不用，一个类最多只能够有一个超类，但是可以同时实现多个接口。

一个接口本身没有任何实现，因此Java接口不涉及表象，而之描述public行为，所以Java接口比Java抽象类更为抽象化。

接口和类的最重要区别是，接口仅仅描述方法的特征，而不给出方法的实现；而类不仅给出方法的特征，而且给出方法的实现。

1.2 接口是对可插入性的保证

接口使可插入性变得可能。

在一个类等级结构中得任何一类都可以实现一个接口，这个接口会影响到此类得所有子类，但是不会影响到此类到任何超类。此类将不得不实现这个接口所规定得方法，而其子类则可以从此类自动集成到这些方法，当然也可以选择置换掉所有到这些方法，或者其中的某一些方法。

这时候，这些子类就具有了可插入性。

关联的可插入性

正如前面所说的，一个对象需要完成一项任务，所以需要知道其他的对象，并且调用其他对象的方法。这个对象对其他对象的知识叫做关联。

如果一个关联不是针对一个具体类的，而是针对一个接口的，那么任何实现这个接口的类就都可以满足要求。换言之，当前对象并不在意所关联的是哪一个具体类，而仅仅关心这个类是否实现了某一个接口。

这样一来，就可以动态地将这个关联从一个具体类转换到另一个具体类，而这样做的唯一条件是它们都实现某个接口。

调用的可插入性

同样，一个对象不可避免地需要调用其他对象的方法。这种调用不一定非得是某一个具体类，而可以是一个接口。这样一来，任何实现了这个接口的具体类都可以被当前对象调用；而当前对象到底调用的是哪一个具体类的实例则完全可以动态地决定的。

因此，接口提供了关联以及方法调用上的可插入性，软件系统的规模越大，生命周期越长，接口的重要性就越大。接口使得软件系统在灵活性和可扩展性、可插入性方面得到保证。

类型

Java接口用声明一个新的类型。

Java设计师应当主要使用Java接口和抽象Java类将软件单位与内部和外部耦合起来。换言之，应当使用Java接口和抽象Java类而不是具体类进行变量的类型声明、参量的类型声明、方法的返还类型声明，以及数据类型的转换等。当然，一个更好的做法是仅仅使用Java接口，而不要使用抽象Java类来做上面这些。

这理想的情况下，一个具体Java类应当只实现Java接口和抽象Java类中声明过的方法，而不应当给出多余的方法。

二、抽象类

2.1 什么是抽象类

抽象类仅提供一个类型的部分实现。抽象类可以有实例变量，以及一个或多个构造子。抽象类可以同时有抽象方法和具体方法。

一个抽象类不会有实例，这些构造子不能被客户端调用来创建实例。一个抽象类的构造子可以被其子类调用，从而使一个抽象类的所有子类都可以由一些共有的实现。而不同的子类可以在此基础上有其自己的实现。
抽象类和子类的这种关系实际上使模板方法模式的应用。

2.2抽象类的用途

抽象类通常代表一个抽象概念，它提供一个继承的出发点。而具体类则不同，具体类可以实例化，应当给出一个有商业逻辑实现的对象模板。由于抽象类不可以实例化，因此一个设计师设计一个新的抽象类，一定是用来继承的。
而这一个声明倒过来也是对的：具体类不是用来继承的。

具体类不是用来继承的。

所有的继承都是从抽象类开始的，所有的具体类都没有子类。
换言之，在一个以继承关系形成的等级结构里面，树叶节点均应当是具体类，而树枝节点应当是抽象类（或是Java接口）
这样的设计是所有的Java设计师都应当努力做到的。

代码重构的建议

假设有两个具体类，类A和类B，类B是类A的子类，那么一个最简单的修改方案当时建立一个抽象类C，然后让类A和类B成为抽象C的子类。
这样所给出的代码重构的例子实际上具有更加广泛的意义，这就是里氏替换原则。

抽象类应当拥有尽可能多的共同代码

在一个抽象类到多个具体类的继承关系中，共同的代码应当尽量的移动到抽象类里。
在一个继承的等级结构中，共同的代码应当尽量向等级结构的上方移动，把重复的代码从子类里面移动到超类里面，可以提高代码的复用率。由于代码在共同超类而不是几个子类出现，在代码发生改变时，设计师只需要修改一个地方。这对代码的复用明显是有利的。

抽象类应当拥有尽可能少的数据

与代码的移动方向相反的是，数据的移动方向是从抽象类到具体类，也即从继承的等级结构的高端向等级结构的低端移动，一个对象的数据不论是否使用都会占用资源，因此数据应当尽量放到具体类或者等级结构的低端。

2.3 基于抽象类的模式和原则

针对抽象编程

针对抽象编程，不要针对具体编程，这就是依赖倒转原则
换言之，应当针对抽象类编程，不要针对具体子类编程，这一原则点出了抽象类对代码复用的一个重要作用。
以“鸡和蛋"的例子解释，就是要把编程针对到"蛋"上，而不是“鸡”身上。

正确使用继承

抽象类是用来继承的，因此抽象类注定要与继承关联在一起。只要可能，尽量使用合成，而不要使用继承来达到复用的目的。

模板方法模式

几乎所有的模式都涉及到了抽象类，但是模板方法模式不仅仅使用抽象类和继承关系作为模式所涉及的角色抽象化，模板方法模式根本就是关于继承的模式。

2.4 什么时候才应当使用继承复用

继承代表“一般化/特殊化”关系，其中基类代表一般，而衍生类代表特殊，衍生类将积累特殊化或扩展化。只有当一下的coad条件全部被满足时，才应当使用继承关系：

1. 子类是超类的一个特殊种类，而不是超类的一个角色，也就是要区分“Has-A”与“Is-A”两种关系的不同。Has-A关系应当使用聚合关系描述，而只有Is-A关系才符合继承关系。
2. 永远不会出现需要将子类换成另一个类的子类的情况。如果设计师不是很肯定一个类会不会在将来变成另一个类的子类的话，就不应当将这个类设计成当前这个超类的子类。
3. 子类具有扩展超类的责任，而不是具有置换掉或注销掉超类的责任。如果子类需要大量地置换掉超类的行为，那么这个子类不应当称为这个超类的子类。
4. 只有在分类学角度上有意义时，才可以使用继承，不要从工具类继承。

里氏替换原则是可否使用继承关系的准绳。上面的coad条件以比里氏替换原则更加通俗易懂的方式讲解了继承的使用，coad条件的表达不如里氏替换原则严格，但是一般而言，凡是不符号coda条件的均不会满足里氏替换原则。coad条件可以作为里氏替换原则的衍生物。

区分“Has-A”与“Is-A”

当一个类是另一个类的角色时，不应当使用继承描述这种关系。如果仔细考察就会发现，这种情况一定不满足里氏替换原则。

IS-A 表示类与类之间的继承关系,在iOS中,你要实现一个控制器,通常是继承与UIViewController的,你自己的控制器和UIViewController之间的关系就是IS-A关系。
<->
HAS-A 表示组合关系,是整体和部分之间的关系,同时 整体必须负责销毁部分,你的控制器里有很多View,控制器与View之间的关系就是HAS-A关系。

详细介绍： JAVA技术内幕_什么是is-a和has-a关系