第五章第二节 设计可复用的软件
5-1节学习了可复用的层次、形态、表现;本节从类、API、框架三个层面学习如何设计可复用软件实体的具体技术。java
Outline
- 设计可复用的类——LSP
- 行为子结构
- 协变与逆变
- Liskov替换原则(LSP)
- 各类应用中的LSP
- 数组是协变的
- 泛型中的LSP
- 为了解决类型擦除的问题-----Wildcards(通配符)
- 设计可复用的类——委派与组合
- 设计可复用库与框架
Notes
## 设计可复用的类——LSP
- 在OOP之中设计可复用的类
- 封装和信息隐藏
- 继承和重写
- 多态、子类和重载
- 泛型编程
- LSP原则
- 委派和组合(Composition)
【行为子结构】程序员
行为子结构的示例一:编程

- 子类知足相同的不变量(同时附加了一个)
- 重写的方法有相同的前置条件和后置条件
- 故该结构知足LSP
行为子结构的示例二:设计模式

- 子类知足相同的不变量(同时附加了一个)
- 重写的方法 start 的前置条件更弱
- 重写的方法 brake 的后置条件更强
- 故该结构知足LSP
行为子结构的示例三:api

【逆变与协变】数组
- 逆变与协变综述:若是A、B表示类型,f(⋅)表示类型转换,≤表示继承关系(好比,A≤B表示A是由B派生出来的子类):
- f(⋅)是逆变(contravariant)的,当A≤B时有f(B)≤f(A)成立;
- f(⋅)是协变(covariant)的,当A≤B时有f(A)≤f(B)成立;
- f(⋅)是不变(invariant)的,当A≤B时上述两个式子均不成立,即f(A)与f(B)相互之间没有继承关系。
- 协变(Co-variance):
- 父类型->子类型:愈来愈具体(specific)。
- 在LSP中,返回值和异常的类型:不变或变得更具体 。
- 栗子:

- 逆变(Contra-variance):
- 父类型->子类型:愈来愈抽象。
- 参数类型:要相反的变化,不变或愈来愈抽象。
- 栗子:

- 但这在Java中是不容许的,由于它会使重载规则复杂化。
总结:安全

(1.子类型(属性、方法)关系;2.不变性,重写方法;3.协变,方法返回值变具体;4.逆变,方法参数变抽象;5.协变,参数变的更具体,协变不安全)架构
【Liskov替换原则(LSP)】 更多参考:LSP的笔记框架
- 里氏替换原则的主要做用就是规范继承时子类的一些书写规则。其主要目的就是保持父类方法不被覆盖。
- 含义:
- 子类必须彻底实现父类的方法
- 子类能够有本身的个性
- 覆盖或实现父类的方法时输入参数能够被放大
- 覆盖或实现父类的方法时输出结果能够被缩小
- LSP是子类型关系的一个特殊定义,称为(强)行为子类型化。在编程语言中,LSP依赖于如下限制:
- 前置条件不能强化
- 后置条件不能弱化
- 不变量要保持或加强
- 子类型方法参数:逆变
- 子类型方法的返回值:协变
- 异常类型:协变
## 各类应用中的LSP
【数组是协变的】
- 数组是协变的:一个数组T[ ] ,可能包含了T类型的实例或者T的任何子类型的实例
- 即子类型的数组能够赋予父类型的数组进行使用,但数组的类型实际为子类型。
- 下面报错的缘由是myNumber指向的仍是一个Integer[] 而不是Number[]
Number[] numbers = new Number[2];
numbers[0] = new Integer(10);
numbers[1] = new Double(3.14);
Integer[] myInts = {1,2,3,4};
Number[] myNumber = myInts;
myNumber[0] = 3.14; //run-time error!
【泛型中的LSP】
- Java中泛型是不变的,但能够经过通配符"?"实现协变和逆变:
- <? extends>实现了泛型的协变:
- List<? extends Number> list = new ArrayList<Integer>();
- <? super>实现了泛型的逆变:
- List<? super Number> list = new ArrayList<Object>();
- 因为泛型的协变只能规定类的上界,逆变只能规定下界,使用时须要遵循PECS(producer--extends, consumer-super):
- 要从泛型类取数据时,用extends;
- 要往泛型类写数据时,用super;
- 既要取又要写,就不用通配符(即extends与super都不用)。
- 泛型是类型不变的(泛型不是协变的)。举例来讲
ArrayList<String>
是List<String>
的子类型
List<String>
不是List<Object>
的子类型
- 在代码的编译完成以后,泛型的类型信息就会被编译器擦除。所以,这些类型信息并不能在运行阶段时被得到。这一过程称之为类型擦除(type erasure)。
- 类型擦除的详细定义:若是类型参数没有限制,则用它们的边界或Object来替换泛型类型中的全部类型参数。所以,产生的字节码只包含普通的类、接口和方法。
- 类型擦除的结果: <T>被擦除 T变成了Object

- Integer是number的子类型,但Box<Integer>也不是Box<Number>的子类型
- 这对于类型系统来讲是不安全的,编译器会当即拒绝它。

【为了解决类型擦除的问题-----Wildcards(通配符)】
- 无界通配符类型使用通配符(
?
)指定,例如List <?>
,这被称为未知类型的列表。
- 在两种状况下,无界通配符是一种有用的方法:
- 若是您正在编写可以使用Object类中提供的功能实现的方法。
- 当代码使用泛型类中不依赖于类型参数的方法时。 例如,
List.size
或List.clear
。 事实上,Class <?>
常常被使用,由于Class <T>
中的大多数方法不依赖于T
。
栗子:
public static void printList(List<Object> list) {
for (Object elem : list)
System.out.println(elem + " ");
System.out.println();
}
printList
的目标是打印任何类型的列表,但它没法实现该目标 ,它仅打印Object
实例列表; 它不能打印List <Integer>
,List <String>
,List <Double>
等,由于它们不是List <Object>
的子类型。
- 要编写通用的
printList
方法,请使用List<?>
- 低边界通配符<? super A> e.g. List<? super Integer> List<Number>
- 上边界通配符<? extends A> e.g. List<? extends Number> List<Integer>
1 public static void printList(List<?> list) {
2 for (Object elem: list)
3 System.out.println();
4 }
5
6 ist<Integer> li = Arrays.asList(1, 2, 3);
7 List<String> ls = Arrays.asList("one", "two", "three");
8 printList(li);
9 printList(ls);

## 委派与组合
【Comparator 和 Comparable(比较器与可比较的)】
咱们先看一个比较排序的例子:

- 引入 int compare(T o1 , T o2):用于比较两个变量的大小。
- 若是你的ADT须要比较大小,或者要放入
Collections
或Arrays
进行排序,可实现Comparator
接口并override compare()
函数。下面为具体例子:

另外一种方法:让你的ADT实现Comparable
接口,而后override compareTo()
方法。与使用Comparator
的区别:不须要构建新的Comparator
类,比较代码放在ADT内部。下面为具体例子。

【委派(Delegation)】
- 委派/委托:一个对象请求另外一个对象的功能 。
- 委派是复用的一种常见形式。
- 分为显性委派:将发送对象传递给接收对象;
- 以及隐性委派:由语言的成员查找规则。
- 下面是一个栗子:能够看到,想在B中调用A,须要先委派一个A。

- 委派设计模式:是一种用来实现委派的软件设计模式;
- 委派依赖于动态绑定,由于它要求给定的方法调用能够在运行时调用不一样的代码段;
- 委派的过程以下:
Receiver对象将操做委托给Delegate对象,同时Receiver对象确保客户端不会滥用委托对象;
- 例子二:使用委派能够继承委派类的功能,这里list是被委派的对象,List的方法add和remove方法均可以经过list在LoggingList中被调用。

【委派与继承】
- 继承:经过新操做扩展基类或覆盖操做。
- 委托:捕获操做并将其发送给另外一个对象。
- 许多设计模式使用继承和委派的组合。

- Problem:若是子类只须要复用父类中的一小部分方法,
- Solution:能够不须要使用继承,而是经过委派机制来实现。
- 本质上,一个类不须要继承另外一个类的所有方法,经过委托机制调用部分方法。

【复合继承原则(CRP)】
- 复合复用原则(CRP):类应当经过它们之间的组合(经过包含其它类的实例来实现指望的功能)达到多态表现和代码复用,而不只仅是从基础类或父类继承。
- 咱们能够将组合(Composition)理解为(has a)而继承理解为(is a);
- 委派能够看作Object层面的复用机制,而继承能够看作是类的层面;
- 下面咱们看一个关于CRP的栗子:
Employee
类具备计算员工年度奖金的方法:
class Employee {
Money computeBonus() {... // default computation}
... }
Employee
的不一样子类:Manager
, Programmer
, Secretary
等可能但愿重写此方法以反映某些类型的员工比其余员工得到更慷慨的奖金这一事实:
class Manager extends Employee {
@Override Money computeBonus() {... // special computation}
... }
- 这个解决方案有几个问题。 全部
Manager
对象得到相同的奖金。 若是咱们想改变管理者之间的奖金计算怎么办?引入Manager
的特殊子类?
class SeniorManager extends Manager {
@Override Money computeBonus() {... // more special computation}
...
}
- 若是咱们想改变特定员工的奖金计算会怎样? 例如,若是咱们想要将史密斯从
Manager
推广到SeniorManager
,该怎么办?
- 若是咱们决定让全部
Manager
得到与Programmer
相同的奖金呢? 咱们是否应该将Programmer
中的计算算法复制并粘贴到Manager
中?
- 核心问题:每一个Employee对象的奖金计算方法都不一样;若是能在object层面实现必定比class层面灵活不少。
- CRP的解决方法:

- 只需针对不一样子类的对象,委派可以计算该子类的奖金的方法的BonusCalculator。这样一来就不须要在子类继承的时候进行重写。
- 【总结】组合来代替继承的更广泛实现:
- 用接口来实现系统的最基础行为
- 接口之间用extends来实现系统功能的扩展(接口组合)
- 类implements 组合接口

【委派的类型】
- 临时性委派(Dependency):最简单的方法,调用类里的方法(use a),其中一个类使用另外一个类而不实际地将其做为属性。

- 永久性委派(Association):类之中有其它类的具体实例来做为一个变量(has a)

- 更强的委派,组合(Composition):更强的委派。将一些简单的对象组合成一个更为复杂的对象。(is part of)

- 聚合(Aggregation):对象是在类的外部生成的,而后做为一个参数传入到类的内部构造器。(has a)

【组合与聚合】
在组合中,当拥有的对象被破坏时,被包含的对象也被破坏。在聚合中,这不必定是真的。以生活中的事物为例:大学拥有多个部门,每一个部门都有一批教授。 若是大学关闭,部门将不复存在,但这些部门的教授将继续存在。 一位教授能够在一个以上的部门工做,但一个部门不能成为多个大学的一部分。大学与部门之间的关系即为组合,而部分与教授之间的关系为聚合。
## 设计可复用库与框架
之因此library和framework被称为系统层面的复用,是由于它们不只定义了1个可复用的接口/类,而是将某个完整系统中的全部可复用的接口/类都实现出来,而且定义了这些类之间的交互关系、调用关系,从而造成了系统总体 的“架构”。、
- 相应术语:
- API(Application Programming Interface):库或框架的接口
- Client(客户端):使用API的代码
- Plugin(插件):客户端定制框架的代码
- Extension Point:框架内预留的“空白”,开发者开发出符合接口要求的代码( 即plugin) , 框架可调用,从而至关于开发者扩展了框架的功能
- Protocol(协议):API与客户端之间预期的交互序列。
- Callback(反馈):框架将调用的插件方法来访问定制的功能。
- Lifecycle method:根据协议和插件的状态,按顺序调用的回调方法。
【API和库】
- API是程序员最重要的资产和“荣耀”,吸引外部用户,提升声誉。
- 建议:始终以开发API的标准面对任何开发任务;面向“复用”编程而不是面向“应用”编程。
- 难度:要有足够良好的设计,一旦发布就没法再自由改变。
- 编写一个API须要考虑如下方面:
- API应该作一件事,且作得很好
- API应该尽量小,但不能过小
- Implementation不该该影响API
- 记录文档很重要
- 考虑性能后果
- API必须与平台和平共存
- 类的设计:尽可能减小可变性,遵循LSP原则
- 方法的设计:不要让客户作任何模块能够作的事情,及时报错
【框架】(内容参考白盒框架与黑盒框架)
- 框架(Framework)是整个或部分系统的可重用设计,表现为一组抽象构件及构件实例间交互的方法;另外一种定义认为,框架是可被应用开发者定制的应用骨架。前者是从应用方面然后者是从目的方面给出的定义。
- 为了增长代码的复用性,可使用委派和继承机制。同时,在使用这两种机制增长代码复用的过程当中,咱们也相应地在不一样的类之间增长了关系(委派或继承关系)。而对于一个项目而言,各个不一样类之间的依赖关系就能够看作为一个框架。一个大规模的项目可能由许多不一样的框架组合而成。
- 框架与设计模式:
- 框架、设计模式这两个概念总容易被混淆,其实它们之间仍是有区别的。构件一般是代码重用,而设计模式是设计重用,框架则介于二者之间,部分代码重用,部分设计重用,有时分析也可重用。在软件生产中有三种级别的重用:内部重用,即在同一应用中能公共使用的抽象块;代码重用,即将通用模块组合成库或工具集,以便在多个应用和领域都能使用;应用框架的重用,即为专用领域提供通用的或现成的基础结构,以得到最高级别的重用性。
- 框架与设计模式虽然类似,但却有着根本的不一样。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述,它比框架更抽象;框架能够用代码表示,也能直接执行或复用,而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素,一个框架中每每含有一个或多个设计模式,框架老是针对某一特定应用领域,但同一模式却可适用于各类应用。能够说,框架是软件,而设计模式是软件的知识。
- 框架分为白盒框架和黑盒框架。
- 白盒框架:
- 白盒框架是基于面向对象的继承机制。之因此说是白盒框架,是由于在这种框架中,父类的方法对子类而言是可见的。子类能够经过继承或重写父类的方法来实现更具体的方法。
- 虽然层次结构比较清晰,可是这种方式也有其局限性,父类中的方法子类必定拥有,要么继承,要么重写,不可能存在子类中不存在的方法而在父类中存在。
- 软件构造课程中有关白盒框架的例子:
public abstract class PrintOnScreen {
public void print() {
JFrame frame = new JFrame();
JOptionPane.showMessageDialog(frame, textToShow());
frame.dispose();
}
protected abstract String textToShow();
}
public class MyApplication extends PrintOnScreen {
@Override protected String textToShow() {
return "printing this text on " + "screen using PrintOnScreen " + "white Box Framework";
}
}
- 经过子类化和重写方法进行扩展(使用继承);
- 通用设计模式:模板方法;
- 子类具备主要方法但对框架进行控制。
- 容许扩展每个非私有方法
- 须要理解父类的实现
- 一次只进行一次扩展
- 一般被认为是开发者框架
- 黑盒框架:
- 黑盒框架时基于委派的组合方式,是不一样对象之间的组合。之因此是黑盒,是由于不用去管对象中的方法是如何实现的,只需关心对象上拥有的方法。
- 这种方式较白盒框架更为灵活,由于能够在运行时动态地传入不一样对象,实现不一样对象间的动态组合;而继承机制在静态编译时就已经肯定好。
- 黑盒框架与白盒框架之间能够相互转换,具体例子能够看一下,软件构造课程中有关黑盒框架的例子,更改上面的白盒框架为黑盒框架:
public interface TextToShow {
String text();
}
public class MyTextToShow implements TextToShow {
@Override
public String text() {
return "Printing";
}
}
public final class PrintOnScreen {
TextToShow textToShow;
public PrintOnScreen(TextToShow tx) {
this.textToShow = tx;
}
public void print() {
JFrame frame = new JFrame();
JOptionPane.showMessageDialog(frame, textToShow.text());
frame.dispose();
}
}
-
-
- 经过实现插件接口进行扩展(使用组合/委派);
- 经常使用设计模式:Strategy, Observer ;
- 插件加载机制加载插件并对框架进行控制。
- 容许在接口中对public方法扩展
- 只须要理解接口
- 一般提供更多的模块
- 一般被认为是终端用户框架,平台