《(2020年)企业管理设计模式简要论述》由会员分享,可在线阅读,更多相关《(2020年)企业管理设计模式简要论述(8页珍藏版)》请在金锄头文库上搜索。
1、GRASP(General Responsibility Assignment Software Patterns)创建者(Creator)问题:谁创建了A?解决方案:如果以下条件之一为真时(越多越好),将创建类A实例的职责分配给B:l B“包含”或组成聚合了Al B记录Al B紧密地使用Al B具有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.ite
3、rator(); 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;
4、return 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();) Tre
5、eNode node = iterator.next();node.print();低耦合(Low Coupling)所谓耦合,即两个对象之间联系的紧密程度问题:如何减少因变化产生的影响?解决方案:分配职责以使耦合保持在较低的水平。低耦合是构建软件最重要的目标之一。要注意:我们讲低耦合,是降低与不稳定系统之间的耦合度,而不是那些稳定的系统,比如说我们在JAVA编程过程中,没有必要想专门的办法来降低与JDK核心类库之间的耦合度,因为JDK核心类库非常稳定,很少会发生变化。高内聚(High Cohesion)所谓内聚,即对象职责的相关性(或对象的操作之间联系的紧密程度)。高内聚,即保持对象职责的高
6、度相关性。不良内聚和不良耦合往往都是齐头并进的!问题:怎样保持对象是有重点的、可理解的、可管理的,并且能够支持低耦合?解决方案:分配职责以保持较高的内聚性。内聚性较低的类,要做许多不相关的工作,或需要完成大量的工作。这样的类是不合理的。这样的类会有下列问题:l 难以理解l 难以复用l 难以维护l 脆弱,经常会受到变化的影响高内聚、低耦合是我们进行系统设计时,应该尽量要达到的目标。但是在某些情况下,这些原则也许不太合适。比如在分布式系统的开发中。分布式系统开发中的分布式对象之间的互相调用,可能会跨越网络,跨网络调用会导致系统性能的下降,为了提高性能,所以必须寻找某种手段来降低跨网络调用的次数。控
7、制器(Controller)问题:在UI层下首先接收和协调(“控制”)系统操作的对象是什么?解决方案:把职责分配给能代表下列选择之一的对象:l 代表整个“系统”、“根对象”(外观控制器)。 - 一般用Faade模式来实现l 代表发生系统操作的用例场景(用例控制器)。 - 如果使用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)软件实体(类、模块、函数等等)应该是可以扩展的,但是不可修改的。1、 对于扩展是开放的这意味着模块的行为是可以扩展的。当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为。2、 对于更改是封闭的对模块的行为进行扩展时,不
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对象时
12、,它将无法处理!要让它符合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.out.println(现在你学习的语言是:+lan.toString();在这种情况下,可以随意定义Language的子类,并传递到saysomething方法,不会有任何问题。依赖倒置原则(DIP)A、 高层模块不应该依赖于底层模块。二者都应该依赖于抽象。B、 抽象不应该依赖于细节。细节应该依赖于抽象。接口隔离原则(ISP)不应该强迫客户依赖于它们不用的方法。(避免“胖”接口)