Embed Size (px)
Citation preview
《Java高级技术》课程设计原则与设计模式
李 戈
北京大学 信息科学技术学院 软件研究所
2008年6月1日
什么是软件设计
需求理解
对软件使用空间及应用方式的理解；
软件建模
对最终软件产品的表达；
软件设计
以满足软件需求为目标；
以软件建模为形式；
一种创造性生产活动；
我们目前的处境
已经具备的能力：
构造一个软件；
继而需要提升的能力：
如何构造一个“好的”软件；
首先考虑的问题：
什么是一个“好的”软件？
软件的永恒之道
Christopher Alexander生机是建筑的永恒之道；
建筑的生机源自其空间模式与人们的事件模
式的吻合；
软件的永恒之道
生机也是软件的永恒之道；
软件的生机来自其结构模式与其使用模式
（生存模式）的吻合；
什么是模式什么是模式
模式是对成功应用经验的总结与复用；
模式在现实生活中随处可见；
模式的由来
建筑领域首先系统地研究了模式的思想与原理，并将
模式用于建筑设计的复用。
著名建筑学家Christopher Alexander等人的经典著作
《建筑模式语言》（A Pattern Language : Towns, Buildings, Construction, Oxford University Press,1977）描述了250 多种设计城镇与建筑物的模式，涉及城镇、
邻里、住宅、花园、房间等多种建筑物。
什么是模式Christopher Alexander
“每一个模式描述了一个在我们周围不断重复发生的问
题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动。”
GoF （Gang of Four）“尽管Alexander所指的是城市和建筑模式，但他的思
想也同样适用于面向对象设计模式，只是在面向对象
的解决方案里，我们用对象和接口代替了墙壁和门窗。两类模式的核心都在于提供了相关问题的解决方案。”
什么是模式Christopher Alexander 的定义
模式是一种由三个部分组成的规则，它描述了
特定环境、问题以及解决方案之间的关系。
背景（context）●指那些适合运用该模式的可重现情形；
问题（problem）
●指出现在背景中的一系列应力，即设计的目标与约束；
解决方案（solution）●是可用于解决问题的经典设计形式或设计规则。
什么是模式一般而言，一个模式有四个基本要素：
模式名称（pattern name）● 一个助记名，用一两个词描述模式的问题、解决方案和效果。
问题(problem) ● 描述应该在何时使用模式；
● 问题存在的前因后果
● 使用模式必须满足的一系列先决条件；
解决方案(solution) ● 描述设计的组成成分，它们之间的相互关系及各自的职责和协作方式；
● 怎样用一个具有一般意义的元素组合（类或对象组合）来解决问题；
效果(consequences) ● 描述了模式应用的效果及使用模式应权衡的问题；
● 所需的时间和空间代价、对系统灵活性、扩充性、可移植性的影响；
什么是设计模式Design Pattern
In software engineering, a design pattern is a generalrepeatable solution to a commonly occurring problem in software design.It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.
How many design patterns?At least 250 existing patterns are used in OO world. The 23 design patterns by GOF are well known.
GoF设计模式GoF（Gang of Four）设计模式
Erich Gamma、Richard Helm、Ralph Johnson 和John Vlissides四人合著的《设计模式：可复用面向对象软件的基础》（Design Patterns:Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995）是面向对象设计模式的开创性著作。
按用途可划分为创建、结构和行为三大类：
为什么需要设计模式设计的臭味——腐化软件的气味
僵化性（Rigidity）：很难对系统进行改动，因为每个改动都会迫使许多对系统其他部分的其他改动。
脆弱性（Fragility）：对系统的改动会导致系统中和改动的地方在概念上无关的许多地方出现问题。
牢固性（Immobility）：很难解开系统的纠结，使之成为一些可在其他系统中复用的组件。
粘滞性（Viscosity）：系统原定的设计方法难以保持，系统的更新通过硬性的修改完成。
不必要的复杂性（Needless Complexity）：设计中包含有不具任何直接好处的基础结构。
不必要的重复（Needless Repetition）：设计中包含有重复的结构，而该重复的结构本可以使用单一的抽象进行统一。
晦涩性（Opacity）：很难阅读、理解。没有很好的表现出意图。
引发Bad Smell的原因
外因
设计与现实世界背离；
设计与实现方法的多样性；
设计需求的变化；
内因
现代计算机的结构；
● 软件运行机制的制约；
事物的复杂性与程序设计语言的限制；
解决之道Robert C. Martin
敏捷软件开发方法的主要倡导者之一
Object Mentor 在技术报告《设计原则与设计模式》（Design Principles and Design Patterns, Technical Report ，http://www.objectmentor.com/, 2000）中汇集了10 条面向对象设计原则；
在其著作《敏捷软件开发：原则、模式与实践》（Agile Software Development, Principles, Patterns, and Practices, Prentice Hall, 2002）中进一步阐述了其
中的一些设计原则。
解决之道
用面向对象的一些原则来指导实践：
单一职责原则
●The Single Responsibility Principle（SRP）开放——封闭原则
●The Open-Close Principle（ OCP）
里氏替换原则
●The Liskov Substitution Principle（ LSP）
依赖倒置原则
●The Dependency Inversion Principle（DIP）
接口隔离原则
●The Interface Segregation Principle（ISP）
单一职责原则（SRP）
Single Responsibility PrincipleThere should never be more than one reason for a class to change.永远不要让一个类存在多个改变的理由。
职责（Responsibility）类的行为，由类的成员方法完成；
职责是为别的类（用户）提供服务的；
是引起类的实现方式变化的原因；
单一职责原则（SRP）
单一职责原则（SRP）
为什么一个类不能有多于一个以上的职责？
如果一个类具有一个以上的职责，那么就会有
多个不同的原因引起该类变化，而这种变化将
影响到该类不同职责的使用者（不同用户）：
●如果一个职责使用了外部类库，则使用另外一
个职责的用户却也不得不包含这个未被使用的
外部类库。
●某个用户由于某个原因需要修改其中一个职
责，另外一个职责的用户也将受到影响，他将
不得不重新编译和部署。
单一职责原则（SRP）
如何应用SRP
单一职责原则（SRP）
如何应用SRP
开放—封闭原则（OCP）The Open-Closed Principle
Software entities (classes, modules, function, etc.) should be open for extension, but closed for modification.软件实体（类、模块、函数等）应该是可以
扩展的（开放），但是不可修改（封闭）；
可以扩展
为软件模块增加新行为，使其具备新功能；
不可修改
不改动软件实体的代码，不更新可执行体；
开放—封闭原则（OCP）
需要遵循开闭原则的原因：
稳定性
●开闭原则要求扩展功能不修改原来的代码，这可以让软件系统在变化中保持稳定。
扩展性
●开闭原则要求对扩展开放，通过扩展提供新的或改变原有的功能，让软件系统具有灵活的可扩展性。
遵循开闭原则的系统设计，可以让软件系统可复用，并且易于维护。
开放—封闭原则（OCP）
应用开放封闭原则
利用“抽象”实现“对扩展是开放的，对修改是
封闭的”；
说明：
应用OCP原则需要付出“提高系统复杂性”的代
价，因此，不要滥用；
适合的时机：在第一次需要对功能进行扩展
时，判定改动是否违反OCP；
OCP的应用（1）public Dog{
public void dogBehavior( ){ System.out.println("我晚上睡觉,白天活动");}public void dogFavoriteFood( ){ System.out.println(“我喜欢吃骨头”)}… …
}
public static Main(){
… …Dog myDog = new Dog();… myDog.dogBehavior() … ; //输出: "我晚上睡觉,白天活动"… …… myDog.dogFavoriteFood() …;… …
}
我有一只宠物小狗
同学小张为我的宠物小狗写了一个管理辅助程序
OCP的应用 (2)public Cat{ public void catBehavior( )
{ System.out.println("我白天睡觉,晚上活动");}public void catFavoriteFood( ){ System.out.println(“我喜欢吃鱼”)}… …
}
public static Main(){
… …Cat myCat = new Cat();… myCat.catBehavior() …; … ……. myCat.catFavoriteFood() …;… …
}
我又得了一只宠物小猫
我希望小张把宠物小狗的管理程序换成宠物猫
OCP的应用 (3)
public abstract class Animal{ public abstract void Behavior( ); //描述各种动物的特性
public abstract void FavoriteFood( ); //描述动物的食物… …
}
public static Main(){
… …Animal myanimal = new XXX();… myanimal.Behavior() … ; … …… myanimal.FavoriteFood()…;… …
}
李老师，你的宠物都差不多吧
我写一个适用于多种宠物的管理程序吧
OCP的应用 (4)public abstract class Animal{ public abstract void Behavior( ); //描述各种动物的特性
public abstract void FavoriteFood( ); //描述各种动物的食物… …
}public Dog extends Animal{
private void Behavior(){ System.out.println("我晚上睡觉,白天活动"); }public void FavoriteFood( ){…};
}public Cat extends Animal{
private void Behavior(){ System.out.println("我白天睡觉,晚上活动"); }public void FavoriteFood( ){…};
}
你可以随便收集小宠物了!只要你可以把小动物“绑定”到
我的程序上，都可以管理！
里氏替换原则（LSP）
OCP主张使用“抽象”和“多态”将设计中的静态
结构改为动态结构，维持设计的封闭性。
“抽象”是语言提供的功能。“多态”由继承语义实现。
问题产生了：“如何度量继承关系的质量？”Liskov于1987年提出了一个关于继承的原则“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“继承必须确保超类所拥有的性质在子类中仍然成立。”
里氏替换原则（LSP）Liskov Substitution Principle
Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.子类型（subtype）必须能够替换掉它们的基类型
（base type）;
所有引用基类的地方必须能透明地使用其子类的对象。
描述
若对于每一个类型S的对象O1，都存在一个类型T的对
象O2，使得在所有针对T编写的程序P中，用O1替换
O2后，程序P的行为功能不变，则S是T的子类型。
class Rectangle {double width;double height;
public double getHeight() {return height;
}public void setHeight(double height) {
this.height = height;}public double getWidth() {
return width;}public void setWidth(double width) {
this.width = width;}
}
class Square extends Rectangle {public void setHeight(double height) {
super.setHeight(height);super.setWidth(height);
}
public void setWidth(double width) {super.setHeight(width);super.setWidth(width);
}}
这里Rectangle是基类，Square从Rectangle继承。
假如已有的系统中存在以下既有的业务
逻辑代码：
void g(Rectangle r) {r.setWidth(5);r.setHeight(4);if (r.getWidth() * r.getHeight() != 20) {
throw new RuntimeException();}
}
则对应于扩展类Square，在调用既有业
务逻辑时：
Rectangle square = new Square();g(square);
时会抛出一个RuntimeException异常。
这显然违反了LSP原则。
里氏替换原则（LSP）举一个例子：
生物学的分类体系中把企鹅归属为鸟类。类“鸟”中有个方法fly，企鹅自然也
继承了这个方法，可是企鹅不能飞；
于是，在企鹅的类中覆盖了fly方法，告诉方法的调用者：企鹅不会飞。
这完全符合常理。但违反了LSP，企鹅是鸟的子类，可是企鹅却不能飞！
里氏替换原则（LSP）
修正后的设计如下：
依赖倒置原则（DIP）
Dependency Inversion Principle (DIP) A. High level modules should not depend upon low level modules. Both should depend upon abstractions.A. 高层模块不应该依赖于低层模块。二者都应该
依赖于抽象实体；
B. Abstractions should not depend upon details. Details should depend upon abstractions.B. 抽象不应该依赖于细节，细节应该依赖于抽象
依赖倒置原则（DIP）
依赖
主要表现为调用，还表现为引用或关联
倒置
传统结构化程序设计中，上层模块依赖于下层模块；
相对于传统设计方式而言，这个原则将关系“倒置”过来；
解决的问题
使得高层的模块能够得以复用；
程序变得灵活而易于进行扩充；
依赖倒置原则（DIP）问题的解决：
在高层模块与低层模块之间，引入一个抽象接口层。High Level Classes（高层模块） --> Abstraction Layer（抽象接口层） --> Low Level Classes（低层模
块）；
抽象接口是对低层模块的抽象，低层模块继承或实现
该抽象接口；
●高层模块不直接依赖低层模块，高层模块与低层模块
都依赖抽象接口层。
●抽象也不依赖低层模块的实现细节，低层模块依赖
（继承或实现）抽象定义。
依赖倒置原则（DIP）Robert C. Martin氏给出的DIP方案的类的结构图：
PolicyLayer-->MechanismInterface(abstract)--MechanismLayer-->UtilityInterface(abstract)--UtilityLayer类与类之间都通过Abstract Layer来组合关系。
依赖倒置原则（DIP）
程序中所有的依赖关系应该终止于抽象类或接口：
任何变量都不应该持有一个指向具体类的引用；
任何类都不应该从具体类派生；
任何方法都不应该重写它的任何基类中已经实现
的方法；
说明：
如果一个具体类不太会改变，并且不会创建其他类
似的派生类，则依赖于它不会造成损害；
“大多数具体类都是不稳定的”；
接口分隔原则（ISP）Interface Segregation Principle（ISP）
Clients should not be forced to depend upon interfaces that they do not use.不能强迫用户去依赖那些他们不使用的接口。
依赖：继承或实现
针对的问题：如果用户被迫依赖他们不使用的接口，当接口发生改变时，他们也不得不跟着改变。
换而言之，一个用户依赖了未使用但被其他用户使用的接口，当其他用户修改该接口时，依赖该接口的所有用户都将受到影响。
接口分隔原则（ISP）解决方案：
接口设计原则：
●接口的设计应该遵循最小接口原则，不要把用户不使用的
方法塞进同一个接口里。
●如果一个接口的方法没有被使用到，应该将其分割成几个
功能专一的接口。
同理：
●如果一个接口a依赖（继承）另一个接口b，则接口a相当于继承了接口
b的方法，那么继承了接口b后的接口a也应该遵循上述原则：不应该包
含用户不使用的方法。
●反之，则说明接口a被b给污染了，应该重新设计它们的关系。
接口分隔原则（ISP）举例说明：
假如有一个Door，有lock，unlock功能，另外，
可以在Door上安装一个Alarm而使其具有报警功
能。用户可以选择一般的Door，也可以选择具有
报警功能的Door。
一种设计方式：
依赖Door接口的CommonDoor却不得不实现未使用的alarm()方法。
违反了ISP原则
接口分隔原则（ISP）
方法二：通过多重继承实现
AlarmDoor有2种实现方案，遵循ISP设计原则：
同时实现Door和Alarm接口；
继承CommonDoor，并实现Alarm接口；
看看这个设计有什么不同方法三：Adapter Design Pattern
设计原则与设计模式设计原则（Design Principle）
面向对象设计的总体指导思想，为软件设计提供总体
指导；
在软件行业被普遍接受的公认设计原则并不多；
设计模式
遵循设计原则提出的具体的面向对象设计技术；
设计模式从已有的成功或失败设计经验中抽象出这些
设计的共性。
不同团体提出的设计模式远多于设计原则，并且数量
还在不断增加。
程序包设计原则
包内聚原则（Package Cohesion Principles）版本复用等价原则；
公共闭包原则；
公共复用原则；
包耦合原则（Package Coupling Principles）无环依赖原则；
稳定依赖原则；
稳定抽象原则；
包内聚原则
版本复用等价原则（Release Reuse Equivalency Principle）
提倡以版本发布的粒度作为软件复用的粒度。
程序包是版本发布的基本单位，因而也应该是
复用的基本单位。
公共闭包原则（Common Closure Principle）
提倡将可能一起变化的类放在同一程序包中。
公共复用原则（Common Reuse Principle）
避免将不是一起复用的类放在同一程序包中。
包耦合原则无环依赖原则（Acyclic Dependencies Principle）
程序包之间的依赖关系不可形成环路。循环依赖导致模块之间的依赖关系激增，从而模块之间关系更加复杂。
稳定依赖原则（Stable Dependencies Principle）主张朝着稳定的方向建立依赖关系。
稳定抽象原则（Stable Abstractions Principle）被大量依赖的程序包应该是抽象的；
通常将不稳定的程序包放在依赖关系的上层，较稳定的程序包则放在依赖关系的底层。
B. Meyer 的设计原则
Bertrand Meyer 面向对象程序设计语言Eiffel 的设计师
在其经典著作《面向对象软件构造》（Object-Oriented Software Construction, 2nd Edition, Prentice Hall, 1997）中提出构造面向
对象软件系统的5 大原则：
B. Meyer 的设计原则语言模块单位原则（Linguistic Modular Units Principle）
模块必须与所用语言的语法单位相对应。
自文档原则（Self-Documentation Principle）一个模块的设计人员应尽量将该模块有关的所有信息表达在该模块自身中。
●高德纳（Donald Knuth）提出的“文学程序设计方法” 是这一设计原则的很好体现。
文学程序设计方法在单个文件中组合了源代码与文档，然后由文学程序设计工具分析该文件，产生可读的文档或可编译的源程序。
●Java 语言除C++语言提供的两类注释风格外，还支
持程序员使用文档化注释。
B. Meyer 的设计原则统一访问原则（Uniform Access Principle）
模块提供的所有服务均应通过一种统一的记号来访问，而不必理会这种服务是通过存储还是通过计算来实现的。●据此设计原则，Eiffel 语言采用同一种记号访问一个对象的数据与操作。
开合原则（Open-Closed Principle）一个模块既要是开放的，也要是封闭的。开放性，是指模块具有良好的可扩展性；封闭性，是指模块不会受到其他修改的影响。
单选原则（Single Choice Principle）如果软件系统需要支持一系列的选择，那么在系统中有且仅有一个模块了解这些选择的全体集合。
谢谢 谢谢 ！！
好好想想，有没有问题？
