设计模式 单一职责

读书笔记：

单一职责原则

单一职责原则并不是极端地要求我们只能为类定义一个职责，而是利用极端的表述方式重点强调，在定义对象职责时，必须考虑职责与对象之间的所属关。

职责必须恰如其分地表现对象的行为，而不至于破坏和谐与平衡的美感，甚至格格不入。换言之，该原则描述的单一职责指的是公开在外的与该对象紧密相关的一组职责。例如，如图2-1所示，在媒体播放器中，可以在MediaPlayer类中定义一组与媒体播放相关的方法，如open()、play()、stop()等。这些方法从职责的角度来讲是内聚的，完全符合单一职责原则中“专注于做一件事”的要求。如果需求发生扩充，还需要提供上传、下载媒体文件的功能，那么在设计时，就应该定义一个新类，如MediaTransfer，由它来承担这一职责，而不是为了方便，草率地将其添加到MediaPlayer类中。

单一职责原则的优点有以下几个方面：■ 降低类的复杂性；■ 提高类的可读性；■ 提高代码的可维护性和复用性；■ 降低因变更引起的风险。

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计是否优良，但“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

2.2 里氏替换原则

里氏替换原则的英文名称是：Liskov Substitution Principle，简称LSP。

2.2.1 里氏替换原则的定义在面向对象的语言中，继承是必不可少的、优秀的语言机制，它主要有以下几个优点：■ 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；■ 提高代码的可重用性；■ 提高代码的可扩展性；■ 提高产品或项目的开放性。相应的，继承也存在缺点，主要体现在以下几个方面：■ 继承是入侵式的。只要继承，就必须拥有父类的所有属性和方法；■ 降低代码的灵活性。子类必须拥有父类的属性和方法，使子类受到限制；■ 增强了耦合性。当父类的常量、变量和方法修改时，必须考虑子类的修改，这种修改可能造成大片的代码需要重构。从整体上看，继承的“利”大于“弊”，然而如何让继承中“利”的因素发挥最大作用，同时减少“弊”所带来的麻烦，这就需要引入“里氏替换原则”。里氏替换原则的定义有以下两种。
第一种定义：If for each object o1 of type S there is an object o2 of type T such that for all programs Pdefined in terms of S,the behavior of P is unchanged when o1 is substituted for o2 then T isa subtype of S.这个定义是最正宗的定义，意思是：如果对一个类型为S的对象o1，都有类型为T的对象o2，使得以S定义的所有程序P在所有的对象o1都代换成o2时，程序P的行为没有发生变化，那么类型T是类型S的子类型。第二种定义：Functions that use pointers or references to base classes must be able to use objects ofderived classes without knowing it.第二个定义意思是：所有引用基类的地方必须能透明地使用其子类对象。清晰明确地说明只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道父类还是子类；但是反过来则不可以，有子类的地方，父类未必就能适应。

2.2.2 里氏替换原则的应用在编译期，Java语言编译器会检查一个程序是否符合里氏替换原则，这是一个无关实现的、纯语法意义上的检查。里氏替换要求凡是使用基类的地方，子类一定适用，因此子类必须具备基类的全部接口。或者说，子类型的接口必须包括全部的基类的接口，而且还有可能更宽。如果一个Java程序破坏这一条件，Java编译器就会在编译程序时抛出错误提示，并停止编译。例如，一个基类Base声明了一个public方法method()，其子类Sub就不能将该方法的访问权限从public改换成为private或protected。即子类不能使用一个低访问权限的方法覆盖基类中的高访问权限的方法。如图2-3所示违反了里氏替换原则，Java编译器根本不会让这样的程序编译通过。

里氏替换原则为良好的继承定义了一个规范，它包含4层含义：■ 子类必须完全实现父类的方法；■ 子类可以有自己的个性；■ 覆盖或实现父类的方法时输入参数可以被放大；■ 覆盖或实现父类的方法时输出结果可以被缩小。
下述内容用于实现任务描述 2.D.2，演示里氏替换原则。如图 2-4 所示，Animal 是一个表示动物的抽象类，只要是动物就都能动，因此提供一个抽象的move()方法；Horse和Bird都是Animal的子类。[插图]图2-4 继承类图





上述代码中，使用基类对象指向子类是允许的，但反过来，使用子类对象指向父类则违反里氏替换原则，会出现错误。注意按照里氏替换原则，当多个类之间存在继承关系时，通常应该使用父类或接口来指向子类的对象（除非需要使用子类特有的方法），这更利于提高系统的可扩展性。在设计模式中体现里氏替换原则的有如下几个模式：■ 策略模式■ 组合模式■ 代理模式

2.3 依赖倒置原则

依赖倒置原则英文名称是：Dependence Inversion Principle，简称DIP。2.3.1 依赖倒置原则的定义依赖倒置原则的原始定义是：High level modules should not depend upon low level modules. Both should depend uponabstractions. Abstractions should not depend upon details. Details should depend uponabstractions.翻译过来，包括三层含义：■ 高层模块不应该依赖低层模块，两者都依赖其抽象；
■ 抽象不依赖细节；■ 细节应该依赖于抽象。传统的过程性系统的设计办法倾向于高层次的模块依赖于低层次的模块；抽象层次依赖于具体层次。“倒置”原则将这个错误的依赖关系倒置了过来，如图2-5所示，由此命名为“依赖倒置原则”。

在Java语言中，抽象就是指接口或抽象类，两者都是不能直接被实例化的；细节就是具体的实现类，实现类实现了接口或继承了抽象类，其特点是可以直接被实例化。依赖倒置原则在Java语言中的表现是：■ 模块间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生；■ 接口或抽象类不依赖于实现类；■ 实现类依赖于接口或抽象类。
依赖倒置原则更加精确的定义就是“面向接口编程”——OOD（Object-Oriented Design）的精髓之一。依赖倒置原则可以减少类间的耦合性，提高系统的稳定性，降低并行开发引起的风险，提高代码的可读性和可维护性。依赖倒置原则是JavaBean、EJB和COM等组件设计模型背后的基本原则。

2.3.2 依赖倒置原则的应用下述内容用于实现任务描述 2.D.3，演示依赖倒置原则的应用。在现实生活中，司机只要会开车，就可以开奔驰车，也可以开宝马车。因此司机不依赖于奔驰车或宝马车，而是通过如图2-6所示的接口，使他们之间的依赖关系倒置。

司机接口只是一个抽象化的概念，是对司机这一类事物的抽象，只要是司机都有一个共同的行为，即“开车”，因此，在IDriver接口中使用drive()方法进行抽象。司机接口IDriver的源代码如下所示。

上述代码中，当司机tom想开奔驰车时，只需要将“new BMW()”改为“new Benz()”即可，这样把“变更”引起的风险降低到最小。注意在Java中，只要定义变量就必须要有类型，一个变量可以有两种类型：表面类型和实际类型，表面类型是在定义的时候赋予的类型，实际类型是创建时对象的类型。例如，tom表面类型是IDriver，实际类型是Driver。依赖倒置原则的本质就是通过抽象（接口或抽象类）使各个类或模块的实现彼此独立，互不影响，实现模块间的松耦合。在项目中使用这个原则只要遵循以下几个规则：■ 每个类尽量都具有接口或抽象类，或者抽象类和接口两者都具备。这是依赖倒置的基本要求，接口和抽象类都是抽象的，有了抽象才可能有依赖倒置；■ 变量的表面类型尽量是接口或者是抽象类；■ 任何类都不应该从具体类派生；■ 尽量不要重写基类的方法。如果基类是一个抽象类，而且这个方法已经实现了，子类尽量不要重写。类之间依赖的是抽象，重写了非抽象方法，对依赖的稳定性会产生一定的影响；

■ 结合里氏替换原则使用。里氏替换原则指出父类出现的地方子类就可以出现，结合依赖倒置原则可以得出一个通俗的规则：接口负责定义抽象方法，并且声明与其他对象的依赖关系，抽象类负责公共构造部分的实现，实现类准确地实现业务逻辑，同时在适当的时候对父类进行细化。依赖倒置的原则在小型项目中很难体现出来，例如，使用SSH框架实现一个简单的小型项目，基本上不费太大的力气就可以完成，是否采用依赖倒置原则影响不大。但是，在一个大中型项目中，采用依赖倒置原则具有非常多的优点，特别是规避一些非技术原因引起的问题。项目越大，需求变化的概率也越大，通过采用依赖倒置原则可以使接口或抽象类对实现类进行约束，从而减少需求变化引起的工作量剧增的情况。人员的变动在大中型项目中也是时常存在的，如果设计优良、代码结构清晰，人员变化对项目的影响基本为零。大中型项目的维护周期一般都很长，采用依赖倒置原则可以让维护人员轻松地扩展和维护。

依赖倒置原则是6个设计原则中最难以实现的原则，它是实现开闭原则的重要途径，依赖倒置原则没有实现，就不能实现对扩展的开放，对修改关闭。在项目中，只要抓住“面向接口编程”就基本抓住了依赖倒置的原则。