设计模式

设计模式的介绍

设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。
面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相互通信的对象之间常见的组织关系。

每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。----Christopher Alexander

 

GoF 23 种设计模式

• 历史性著作《设计模式：可复用面向对象软件的基础》一书中描述了23种经典面向对象设计模式，创立了模式在软件设计中的地位。该书四位作者被人们并称为Gang of Four （GoF），“四人组”，该书描述的23种经典设计模式又被人们称为GoF 23 种设计模式。

• 由于《设计模式：可复用面向对象软件的基础》一书确定了设计模式的地位，人们通常所说的设计模式隐含地表示“面向对象设计模式”。但这并不意味“设计模式”就等于“面向对象设计模式”，也不意味着GoF 23种模式就表示了所有的“面向对象设计模式”。除了“面向对象设计模式”外，还有其他设计模式。除了GoF 23种设计模式外，还有更多的面向对象设计模式。

• GoF 23 种设计模式是学习面向对象设计模式的起点，而非终点；本培训课程的目标是让学员在建立在有效方法的基础上，掌握GoF 23 种设计模式。

设计模式与面向对象

• 面向对象设计模式解决的是“类与相互通信的对象之间的组织关系，包括它们的角色、职责、协作方式几个方面。

• 面向对象设计模式是“好的面向对象设计”，所谓“好的面向对象设计”是那些可以满足 “应对变化，提高复用”的设计。

• 面向对象设计模式描述的是软件设计，因此它是独立于编程语言的，但是面向对象设计模式的最终实现仍然要使用面向对象编程语言来表达

• 面向对象设计模式不像算法技巧，可以照搬照用，它是建立在对“面向对象”纯熟、深入的理解的基础上的经验性认识。掌握面向对象设计模式的前提是首先掌握“面向对象”！

从编程语言直观了解面向对象

• 各种面向对象编程语言相互有别，但都能看到它们对面向对象三大机制的支持，即： “封装、继承、多态”

–  封装，隐藏内部实现

–  继承，复用现有代码

–  多态，改写对象行为

 

• 使用面向对象编程语言（如java、C#），可以推动程序员以面向对象的思维来思考软件设计结构，从而强化面向对象的编程范式。

 但OOPL并非面向对象的全部
• 通过面向对象编程语言（OOPL）认识到的面向对象，并不是面向对象的全部甚至只是浅陋的面向对象。

• OOPL的三大机制“封装、继承、多态” 可以表达面向对象的所有概念，但三大机制本身并没有刻画出面向对象的核心精神。换言之，既可以用这三大机制做出“好的面向对象设计”，也可以用这三大机制做出“差的面向对象设计”。不是使用了面向对象的语言（例如java/C#），就实现了面向对象的设计与开发！因我们不能依赖编程语言的面向对象机制，来掌握面向对象。

• OOPL没有回答面向对象的根本性问题——我们为什么要使用面向对象？我们应该怎样使用三大机制来实现“好的面向对象”？ 我们应该遵循什么样的面向对象原则？

• 任何一个严肃的面向对象程序员（例如java程序员），都需要系统地学习面向对象的知识，单纯从编程语言上获得的面向对象知识，不能够胜任面向对象设计与开发。

从一个示例谈起

我们需要设计一个人事管理系统，其中的一个功能是对各种不同类型的员工，计算其当月的工资——不同类型的员工，拥有不同的薪金计算制度。

示例场景：

结构化做法

1、获得人事系统中所有可能的员工类型

2、根据不同的员工类型所对应的不同的薪金制度，计算其工资

enum EmployeeType{

Engineer;

Sales;

Manager;

…

}

// 计算工资程序

If ( type==EmployeeType.Engineer) {

……

}

else if (type== Employeetype.Sales) {

……

}

1。根据不同的员工类型设计不同的类，并使这些类继承自一个Employee抽象类其中有一个抽象方法GetSalary。

2。在各个不同的员工类中，根据自己的薪金制度，重写（override）GetSalary方法。

abstract class Employee{

…

public abstract int GetSalary();

}

class Engineer: Employee{

…

public override int GetSalary() {

……

}

}

class Sales: Employee{

…

public override int GetSalary() {

……

}

}

// 显示工资程序

Employee e= emFactory.GetEmployee(id);

MessageBox.Show( e.GetSalary());

现在需求改变了……

随着客户公司业务规模的拓展，又出现了更多类型的员工，比如钟点

工、计件工……等等，这对人事管理系统提出了挑战——原有的程序

必须改变。

示例场景：

结构化做法

几乎所有涉及到员工类型的地方（当然包括“计算工资程序”）都需要做改变……这些代码都需要重新编译，重新部署…….

面向对象做法

只需要在新的文件里增添新的员工类，让其继承自Employee抽象类，并重写GetSalary()方法，然后在EmployeeFactory.GetEmployee

方法中根据相关条件，产生新的员工类型就可以了。其他地方（显示

工资程序、Engineer类、Sales类等）则不需要做任何改变。

 

重新认识面向对象

• 对于前面的例子，从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小

• 从微观层面来看，面向对象的方式更强调各个类的“责任”，新增员工类型不会影响原来员工类型的实现代码——这更符合真实的世界，也

更能控制变化所影响的范围，毕竟Engineer类不应该为新增的“钟点工”来买单……

• 对象是什么？

– 从概念层面讲，对象是某种拥有责任的抽象。

– 从规格层面讲，对象是一系列可以被其他对象使用的公共接口。

– 从语言实现层面来看，对象封装了代码和数据。

• 有了这些认识之后，怎样才能设计“好的面向对象”？

– 遵循一定的面向对象设计原则

– 熟悉一些典型的面向对象设计模式

 

从设计原则到设计模式

• 针对接口编程，而不是针对实现编程

– 客户无需知道所使用对象的特定类型，只需要知道对象拥有客户所期望

的接口。

• 优先使用对象组合，而不是类继承

– 类继承通常为“白箱复用”，对象组合通常为“黑箱复用”。继承在某种程度上破坏了封装性，子类父类耦合度高；而对象组合则只要求被组合的对象具有良好定义的接口，耦合度低。

• 封装变化点

– 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行

修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。

• 使用重构得到模式——设计模式的应用不宜先入为主，一上来就使用

设计模式是对设计模式的最大误用。没有一步到位的设计模式。敏捷

软件开发实践提倡的“Refactoring to Patterns”是目前普遍公认的最好

的使用设计模式的方法。

 

几条更具体的设计原则

• 单一职责原则（SRP）：

– 一个类应该仅有一个引起它变化的原因。

• 开放封闭原则（OCP）：

– 类模块应该是可扩展的，但是不可修改（对扩展开放，对更改封闭）

• Liskov替换原则（LSP）:

– 子类必须能够替换它们的基类

• 依赖倒置原则（DIP）：

– 高层模块不应该依赖于低层模块，二者都应该依赖于抽象。

– 抽象不应该依赖于实现细节，实现细节应该依赖于抽象。

• 接口隔离原则（ISP）：

– 不应该强迫客户程序依赖于它们不用的方法。

 

总结

• 设计模式描述了软件设计过程中某一类常见问题的一般性的解决方案。

面向对象设计模式描述了面向对象设计过程中、特定场景下、类与相

互通信的对象之间常见的组织关系。

• 深刻理解面向对象是学好设计模式的基础，掌握一定的面向对象设计

原则才能把握面向对象设计模式的精髓，从而实现灵活运用设计模式。

• 三大基本面向对象设计原则

– 针对接口编程，而不是针对实现编程

– 优先使用对象组合，而不是类继承

– 封装变化点

• 使用重构得到模式。敏捷软件开发实践提倡的“Refactoring to

Patterns”是目前普遍公认的最好的使用设计模式的方法。

扩展：

组合对象：要将多个元素作为一个对象来处理,您需要将它们组合。例如,创建了一幅绘画后(如树或花),可以将该绘画的元素合成一组,这样就可以将该绘画当成一个整体来选择和移动。

一个含有其他类对象的类称为组合类，组合类的对象称为组合对象。

对象的组合

一个类可以把对象作为自己的成员变量，如果用这样的类创建对象，那么该对象中就会有其它对象，也就是说该对象将其他对象作为自己的组成部分（这就是人们常说的Has-A），或者说该对象是由几个对象组合而成。

 

 

《极限编程》(Extreme programming)的指导原则之一是“只要能用，就做最简单的”。一个似乎需要继承的设计常常能够戏剧性地使用组合来代替而大简化，从而使其更加灵活。因此，在考虑一个设计时，问问自己：“使用组合是不是更简单？这里真的需要继承吗？它能带来什么好处？”

继承和组合的比较:

　　面向对象系统中功能复用的两种最常用技术是类继承和对象组合(object composition)。正如我们已解释过的，类继承允许你根据其他类的实现来定义一个类的实现。这种通过生成子类的复用通常被称为白箱复用(white-box reuse)。术语“白箱”是相对可视性而言：在继承方式中，父类的内部细节对子类可见。

　　对象组合是类继承之外的另一种复用选择。新的更复杂的功能可以通过组装或组合对象来获得。对象组合要求被组合的对象具有良好定义的接口。这种复用风格被称为黑箱复用(black-box reuse)，因为对象的内部细节是不可见的。对象只以“黑箱”的形式出现。

  继承和组合各有优缺点。类继承是在编译时刻静态定义的，且可直接使用，因为程序设计语言直接支持类继承。类继承可以较方便地改变被复用的实现。当一个子类重定义一些而不是全部操作时，它也能影响它所继承的操作，只要在这些操作中调用了被重定义的操作。

  但是类继承也有一些不足之处。首先，因为继承在编译时刻就定义了，所以无法在运行时刻改变从父类继承的实现。更糟的是，父类通常至少定义了部分子类的具体表示。因为继承对子类揭示了其父类的实现细节，所以继承常被认为“破坏了封装性” 。子类中的实现与它的父类有如此紧密的依赖关系，以至于父类实现中的任何变化必然会导致子类发生变化。当你需要复用子类时，实现上的依赖性就会产生一些问题。如果继承下来的实现不适合解决新的问题，则父类必须重写或被其他更适合的类替换。这种依赖关系限制了灵活性并最终限制了复用性。一个可用的解决方法就是只继承抽象类，因为抽象类通常提供较少的实现。

  对象组合是通过获得对其他对象的引用而在运行时刻动态定义的。组合要求对象遵守彼此的接口约定，进而要求更仔细地定义接口，而这些接口并不妨碍你将一个对象和其他对象一起使用。这还会产生良好的结果：因为对象只能通过接口访问，所以我们并不破坏封装性；只要类型一致，运行时刻还可以用一个对象来替代另一个对象；更进一步，因为对象的实现是基于接口写的，所以实现上存在较少的依赖关系。

　　对象组合对系统设计还有另一个作用，即优先使用对象组合有助于你保持每个类被封装，并被集中在单个任务上。这样类和类继承层次会保持较小规模，并且不太可能增长为不可控制的庞然大物。另一方面，基于对象组合的设计会有更多的对象 (而有较少的类)，且系统的行为将依赖于对象间的关系而不是被定义在某个类中。

　　这导出了我们的面向对象设计的第二个原则：优先使用对象组合，而不是类继承。