每一个设计模式都集中于一个特定的面向对象设计问题或设计要点,描述了什么时候使用它,在另一些设计约束条件下是否还能使用,以及使用的效果和如何取舍。按照设计模式的目的可以分为创建型、结构型和行为型三大类。创建型模式与对象的创建有关;结构型模式处理类或对象的组合;行为型模式对类或对象怎样交互和怎样分配职责进行描述。每种设计模式都有其适应性,描述适用于解决的问题场合。
采用UML对系统进行建模时,首先确定系统边界,识别出主要用例,建模用例图。然后对用例图中的复杂用例采用活动图进一步进行建模,以对用例中执行过程中对象如何通过消息相互交互进行建模。系统的领域模型采用类图进行建模,交互关系采用顺序图、交互概览图等进行建模。每种设计模式都有特定的意图和适用场景,描述一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心,使该方案能够重用而不必做重复劳动。
行为设计模式大多注重封装变化,当一个程序的某个方面的特征经常发生改变时,这些模式就定义一个封装这个方面的对象。这样,当该程序的其他部分依赖于这个方面时,它们都可以与此对象协作。这些模式通常定义一个抽象类来描述这些封装变化的对象,并且通常该模式依据这个对象来命名。例如:一个Strategy对象封装一个算法,一个Mediator对象封装对象间的协议。Mediator和 Observer是相互竞争的模式,之间的差别是:Observer通过引入Observer和Subject对象来分布通信,而Mediator对象则封装了其他对象间的通信。
创建型模式包括 Factory Method(工厂模式-类)、Abstract Factory(抽象工厂)、Builder(生成器)、Prototype(原型) 和 Singleton(单例)。
行为型模式包括 Interpreter(类)、Template Method(类)、Chain of Responsibility(责任链)、 Command(命令)、Iterator(解释器)、Mediator(中介者)、Memento(备忘)、Observer(观察者)、State(状态)、Strategy(策略) 和 Visitor。
外观(Facade)模式为子系统中的各类(或结构与方法)提供一个简明一致的界面,隐藏子系统的复杂性,使子系统更加容易使用。它是为子系统中的一组接口所提供的一个一致的界面。
Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。适用于:要为一个复杂子系统提供一个简单接口时,子系统往往因为不断演化而变得越来越复杂;客户程序与抽象类的实现部分之间存在着很大的依赖性;当需要构建一个层次结构的子系统时,使用Facade模式定义子系统中每层的入口点。
享元(Flyweight)模式运用共享技术有效地支持大量细粒度的对象。适用于:一个应用程序使用了大量的对象;完全由于使用大量的对象,造成很大的存储开销;对象的大多数状态都可变为外部状态;如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象:应用程序不依赖于对象标识。
装饰器(Decorator)模式描述了以透明围栏来支持修饰的类和对象的关系,动态地给一个对象添加一些额外的职责,从增加功能的角度来看,装饰器模式相比生成子类更加灵活。适用于:在不影响其他对象的情况下,以动态、透明的方式给单个对象添加职责;处理那些可以撤销的职责;当不能采用生成子类的方式进行扩充时。
工厂方法(Factory Method)定义一个用于创建对象的接口,让子类决定将哪-个类实例化,使一个类的实例化延迟到其子类。适用于:当一个类不知道它所必须创建的对象的类的时候;当一个类希望由它的子类来指定它所创建的对象的时候;当类将创建对象的职责委托给多个帮助子类中的某一个,并且希望将哪一个帮助子类是代理者这一信息局部化的时候。
观察者(Observer)模式定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。适用于:当一个抽象模型有两个方面,其中一个方面依赖于另一个方面,将这两者封装在独立的对象中以使它们可以各自独立地改变和复用;当对一个对象的改变需要同时改变其他对象,而不知道具体有多少对象有待改变时;当一个对象必须通知其他对象,而它又不能假定其他对象是谁,即不希望这些对象是紧耦合的。
中介者(Mediator)用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显式地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。适用于:一组对象以定义良好但是复杂的方式进行通信,产生的相互依赖关系结构混乱且难以理解;一个对象引用其他很多对象并且直接与这些对象通信,导致难以复用该对象;想定制一个分布在多个类中的行为,而又不想生成太多的子类。欲使一个后端数据模型能够被多个前端用户界面连接,采用中介者模式最合适。
解释器(Interpreter)设计模式是给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。
策略(Strategy)设计模式定义一系列算法,把它们一个个封装起来,并且使它们可相互替换。这一模式使得算法可独立于它的客户而变化。
抽象工厂(Abstract Factory)模式提供一个创建一系列相关或相互依赖对象的接口,而无需指定他们具体的类。抽象工厂模式适用于一个系统要独立于它的产品的创建、组合和表示时;一个系统要由多个产品系列中的一个来配置时;当要强调一系列相关的产品对象的设计以便进行联合使用时:当提供一个产品类库,而只想显示它们的接口而不是实现时。
原型(Prototype)模式用原型实例指定创建对象的种类,并且通过拷贝这个原型来创建新的对象。原型模式适用于:当要实例化的类是在运行时刻指定时,例如通过动态装载,为了避免创建一个与产品类层次平行的工厂类层次时;当一个类的实例只能有几个不同状态组合中的一种时,建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。
适配器(Adapter)模式将一个类或对象的接口转换成客户希望的另外一个接口,使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。适用于想使用一个已经存在的类,而其接口不符合要求的情况。既是类结构模式,又是对象结构模式。
责任链(Chain of Responsibility)模式使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。适用于有多个的对象可以处理一个请求,哪个对象处理该请求运行时刻自动确定的情况。
桥接(Bridge)模式将抽象部分与其实现部分分离,使它们都可以独立地变化。适用于不希望在抽象和它的实现部分之间有一个固定的绑定关系的情况。适配器模式和桥接模式具有类似的特征,都给另一个对象提供了一定程度上的间接性,都涉及到自身以外的一个接口向这个对象转发请求。
命令模式的特点为:将一个请求封装为一个对象,从而可用不同的请求对客户进行参数化,将请求排队或记录请求日志,支持可撤销的操作.
Proxy(代理)模式的结构图如下所示: Proxy模式适用于在需要比较通用和复杂的对象指针代替简单的指针的时候,常见情况有:远程代理(Remote Proxy)为一个对象在不同地址空间提供据不代表;虚代理 (Virtual Proxy)根据需要创建开销很大的对象;保护代理(Protection Proxy)控制对原始对象的访问,用于对象应该有不同的访问权限的时候;智能指引(Smart Reference) 取代了简单的指针,它在访问对象时执行一些附加操作。
Builder(生成器)模式的结构图如下所示: 生成器(Builder)模式将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。生成器模式适用于当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时:当构造过程必须允许被构造的对象有不同的表示时。
Composite(组合)模式的结构图如下所示: 组合(Composite)模式将对象组合成树形结构以表示“部分-整体”的层次结构,使得用户对单个对象和组合对象的使用具有一致性。适用于:想表示对象的部分-整体层次结构;希望用户忽略组合对象与单个对象的不同,用户将统一地使用组合结构中的所有对象。
Observer(观察者)模式的结构图如下所示: 观察者Observer模式适用于:.当一个抽象模型有两个方面,其中一个方面依赖于另一个方面。将这两者封装在独立地对象中以使它们可以各自独立地改变和复用;当对一个对象的改变需要同时改变其他对象.而不知道具体有多少对象有待改变时;当一个对象必须通知其他对象,而它又不能假定其他对象是谁,即不希望这些对象是紧耦合的。(Observer)模式定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。