设计模式简要论述

1、GRASP(General Responsibility Assignment Software Patterns)创建者（Creator）问题：谁创建了A？解决方案：假如以下条件之一为真时（越多越好），将创建类A实例的职责分配给B：B“包含”或组成聚合了AB记录AB紧密地使用AB具有A的初始化数据举例：比如在富客户端应用开发中，主程序创建一个主窗口对象，然后有主窗口对象来负责创建它内部的各种菜单、按钮等对象（而不是由主程序来创建这些菜单或按钮对象之后，再把它设置到主窗口中去）信息专家(Information Expert)问题：给对象分配职责的差不多原则是什么？解决方案：把职责分配给具有完成

2、该职责所需信息的那个类。（描述一种直觉！）举例：public class Classes private int id;private Set students;/描述一种直觉public void addStudent(Student student)if(students = null)students = new HashSet();students.add(student);/将职责放在拥有那个职责所需信息的那个类中public boolean hasStudent(Student student)for (Iterator iterator = students.iterator()

3、; iterator.hasNext();) Student s = (Student) iterator.next();if(s.equals(student)return true;return false;public class Student private int id;private String name;/推断两个学生对象是否相同的职责，交给Student来完成，因为它拥有那个/职责所需要的所有信息public boolean equals(Student student) if(name.equals(student.getName()return true;return

4、false;public class TreeNode private int id;private int level;private String nodeName;private TreeNode parent;private List children;public void print()for(int i=0; ilevel; i+)System.out.print(-);System.out.println(nodeName);for (Iterator iterator = children.iterator(); iterator.hasNext();) TreeNode n

5、ode = iterator.next();node.print();低耦合(Low Coupling)所谓耦合，即两个对象之间联系的紧密程度问题：如何减少因变化产生的阻碍？解决方案：分配职责以使耦合保持在较低的水平。低耦合是构建软件最重要的目标之一。要注意：我们讲低耦合，是降低与不稳定系统之间的耦合度，而不是那些稳定的系统，比如讲我们在JAVA编程过程中，没有必要想专门的方法来降低与JDK核心类库之间的耦合度，因为JDK核心类库特不稳定，专门少会发生变化。高内聚（High Cohesion）所谓内聚，即对象职责的相关性（或对象的操作之间联系的紧密程度）。高内聚，即保持对象职责的高度相关性。不

6、良内聚和不良耦合往往差不多上齐头并进的！问题：如何样保持对象是有重点的、可理解的、可治理的，同时能够支持低耦合？解决方案：分配职责以保持较高的内聚性。内聚性较低的类，要做许多不相关的工作，或需要完成大量的工作。如此的类是不合理的。如此的类会有下列问题：难以理解难以复用难以维护脆弱，经常会受到变化的阻碍高内聚、低耦合是我们进行系统设计时，应该尽量要达到的目标。然而在某些情况下，这些原则也许不太合适。比如在分布式系统的开发中。分布式系统开发中的分布式对象之间的互相调用，可能会跨越网络，跨网络调用会导致系统性能的下降，为了提高性能，因此必须查找某种手段来降低跨网络调用的次数。操纵器（Controll

7、er）问题：在UI层下首先接收和协调（“操纵”）系统操作的对象是什么？解决方案：把职责分配给能代表下列选择之一的对象：代表整个“系统”、“根对象”（外观操纵器）。 - 一般用Faade模式来实现代表发生系统操作的用例场景（用例操纵器）。 - 假如使用Faade来实现一个外观操纵器，会使得那个操纵器特不臃肿，那么能够考虑采纳用例操纵器。举例：比如讲，“导入组织机构的数据”用例，要求能够在界面上上传两个Excel文件，一个Excel是部门信息，一个Excel是人员信息。那么在实现那个用例的时候，UI层在接收到数据之后，应该将业务逻辑统一交给一个业务逻辑处理对象来完成。专门显然，那个业务逻辑对象，需

8、要调度Excel处理相关的对象、人员信息处理相关的对象、部门信息处理相关的对象等来完成那个导入数据的业务。此业务逻辑对象确实是用例操纵器。要注意：MVC中的C，并不是我们那个地点的操纵器。因为MVC中的C处于UI层，而不是业务逻辑层。多态（Polymorphism）问题：如何处理基于类型的选择？如何创建可插拔的软件构件？解决方案：当相关选择或行为随类型（类）有所不同时，使用多态操作为变化的行为类型分配职责。不要测试对象的类型，也不要使用条件逻辑来执行基于类型的不同选择。纯虚构（Pure Fabrication）问题：当你并不想违背高内聚和低耦合或其它目标，然而基于专家模式所提供的方案又不合适时

9、，哪些对象应该承担这一职责？（专门多情况下，只对领域对象分配职责会导致不良内聚或耦合，或者降低复用潜力）解决方案：对人为制造的类分配一组高内聚的职责，该类并不代表问题领域的概念虚构的事物，用以支持高内聚，低耦合和复用。所有GOF设计模式（或其它模式）差不多上纯虚构。间接性（Indirection）问题：为了幸免两个或多个事物之间的直接耦合，应该如何分配职责？如何使对象解耦合，以支持低耦合并提供复用性潜力？解决方案：将职责分配给中介对象，幸免它们之间的直接耦合。中介实现了间接性。大量GOF模式，如适配器、外观等等差不多上间接性的体现。防止变异（Protected Variation）问题：如何设

10、计对象、子系统和系统，使其内部的变化或不稳定性可不能对其它元素产生不良阻碍？解决方案：识不可能变化或不稳定之处，分配职责用以在这些变化之外创建稳定接口。几乎所有的软件或架构设计技巧，差不多上防止变异的特例，比如封装、多态、接口、虚拟机、配置文件等等等等！OOD原则单一职责原则（SRP）就一个类而言，应该仅有一个引起它变化的缘故。开放-封闭原则（OCP）软件实体（类、模块、函数等等）应该是能够扩展的，然而不可修改的。关于扩展是开放的这意味着模块的行为是能够扩展的。当应用的需求改变时，我们能够对模块进行扩展，使其具有满足那些改变的新行为。关于更改是封闭的对模块的行为进行扩展时，不必改动模块的源代码

11、或者二进制代码。OCP背后的要紧机制是抽象与多态！Liskov替换原则（LSP）子类型必须能够替换掉它们的基类型。简单的例子：违反LSP原则的例子public void saysomething(Language lan)String tempStr = ;if(lan instanceof Chinese)tempStr = 中文;if(lan instanceof English)tempStr = 英文;System.out.println(现在你学习的语言是：+tempStr);因为假如传递到saysomething方法中的Language是一个Japanese对象时，它将无法处理！要让它符合LSP也特不简单：public abstract class Language public abstract String toString();public class Chinese extends LanguageOverridepublic String toString() return 中文;public class English extends LanguageOverridepublic String toString() return 英语;public void saysomething(Language lan)System