摘要：
概述在软件系统中，经常面临着“某个对象”的创建工作，由于需求的变化，这个对象的具体实现经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化？提供一种封装机制来隔离出“这个易变对象”的变化，从而保持系统中“其它依赖该对象的对象”不随着需求的改变而改变？这就是要说的Factory Method模式了。意图定义一个用户创建对象的接口，让子类决定实例化哪一个类。Factory Method使一个类的实例化延迟到其子类。结构图角色说明:抽象工厂（Creator）角色：是工厂方法模式的核心，与应用程序无关。任何在模式中创建的对象的工厂类必须实现这个接口。具体工厂（Concrete Creat 阅读全文
摘要：
概述在软件构建过程中，如果某一特定领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。意图 给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。结构图角色说明:AbstractExpression: - 声明一个抽象的Interpret方法，抽象语法树中所有的节点都必须实现该抽象方法。TerminalExpression:- 实现和语法中末端符号相关的Interpret方法。- 在每个句子的末 阅读全文
摘要：
概述在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性。意图 在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原先保存的状态。结构图角色说明:Memento(备忘录)：保存Originator对象的内部状态(主动权在Originator)，提供宽接口给Originator，提供窄接口给CareTaker。 Originator(原发器)： 阅读全文
摘要：
概述表示一个作用于某对象结构中的元素操作。它使你可以在不改变各元素类的前提下定义作用于这些元素的新操作，它把数据结构和作用于结构上的操作之间的耦合性解脱开，使的操作结合可以相对自由地演化。优点是增加新的操作很容易，因为增加一个新的操作就意味着增加一个新的访问者，访问者模式将有关的行为集中到一个访问对象中。意图 实现通过统一的接口访问不同类型元素的操作，并且通过这个接口可以增加新的操作而不改变元素的类。结构图角色说明:访问者角色(Visitor)：为该对象结构中具体元素角色声明一个访问操作接口。该操作接口的名字和参数标识了发送访问请求给具体访问者的具体元素角色。这样访问者就可以通过该元素角色的特 阅读全文
摘要：
概述在软件构建过程中，经常会出现多个对象互相关联交互的情况， 对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。 在这种情况下，我们可使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。 意图 用一个中介对象来封装一系列的对象交互。 中介者使各对象不需要显式的相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。结构图角色说明:Mediator：抽象调停者角色,它定义出同事对象到调停者对象得接口,这个角色一般由Java抽象类实现 ConcreteMediator：具体调停者模式,从抽象调 阅读全文
摘要：
概述在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显示指定，将必不可少地带来请求发送者与接受者的紧耦合。 如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。意图责任链模式是一种对象的行为模式【GOF95】。在责任链模式里，很多对象由每一个对象对其下家的引用而连接起来形成一条链。请求在这个链上传递，直到链上的某一个对象决定处理此请求。发出这个请求的客户端并不知道链上的哪一个对象最终处理这个请求，这使得系统可以在不影响客户端的情况下动态地重新组织链和分配责任。结构图抽象处理者(Handler)角色：定义出一 阅读全文
摘要：
概述变化一直以来都是软件设计的永恒话题，在XP编程中提倡拥抱变化，积极应对。如何更好的去抓住变化点，应对变化？如何更好的提高代码复用？通过学习Template Method模式，您应该有一个新的认识。意图定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。Template Method使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。[-GOF《设计模式》]结构图图1 Template Method 模式结构图生活中的例子模板方法定义了一个操作中算法的骨架，而将一些步骤延迟到子类中。房屋建筑师在开发新项目时会使用模板方法。一个典型的规划包括一些建筑平面图，每个平面图体现了不同部 阅读全文
摘要：
概述面向对象的思想很好地解决了抽象性的问题，一般也不会出现性能上的问题。但是在某些情况下，对象的数量可能会太多，从而导致了运行时的代价。那么我们如何去避免大量细粒度的对象，同时又不影响客户程序使用面向对象的方式进行操作？意图运用共享技术有效地支持大量细粒度的对象。[GOF 《设计模式》]结构图1．单纯享元模式的结构在单纯享元模式中，所有的享元对象都是可以共享的。单纯享元模式所涉及的角色如下：抽象享元(Flyweight)角色：此角色是所有的具体享元类的超类，为这些类规定出需要实现的公共接口。那些需要外蕴状态(External State)的操作可以通过调用商业方法以参数形式传入。具体享元(Co 阅读全文
摘要：
概述 在软件开发系统中，客户程序经常会与复杂系统的内部子系统之间产生耦合，而导致客户程序随着子系统的变化而变化。那么如何简化客户程序与子系统之间的交互接口？如何将复杂系统的内部子系统与客户程序之间的依赖解耦？这就是要说的Façade 模式。重新进行类的设计，将原来分散在源码中的类/结构及方法重新组合，形成新的、统一的接口，供上层应用使用。 Facade所面对的往往是多个类或其它程序单元，通过重新组合各类及程序单元，对外提供统一的接口/界面。意图为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。[GOF 《设计模式》]示意图 阅读全文
摘要：
概述组合模式有时候又叫做部分-整体模式，它使我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以向处理简单元素一样来处理复杂元素,从而使得客户程序与复杂元素的内部结构解耦。描述Composite模式的最佳方式莫过于树形图。从抽象类或接口为根节点开始，然后生枝发芽，以形成树枝节点和叶结点。因此，Composite模式通常用来描述部分与整体之间的关系，而通过根节点对该结构的抽象，使得客户端可以将单元素节点与复合元素节点作为相同的对象来看待。意图将对象组合成树形结构以表示“部分-整体”的层次结构。Composite模式使得用户对单个对象和组合对象的使用具有一致性。[GOF 《设计模式》 阅读全文
摘要：
概述 在软件系统中，有时候我们会使用继承来扩展对象的功能，但是由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性；并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？这就是本文要讲的Decorator模式。 一个场景是我们要为一个对象动态添加新的职责，这个职责并不修改原有的行为，而是在原有行为基础上添加新的功能，就好比装饰工人为一座新居的墙上涂抹上色彩缤纷的颜料一般。 意图 动态地给一个对象添加一些额外的 阅读全文
摘要：
概述在软件系统中，某些类型由于自身的逻辑，它具有两个或多个维度的变化，那么如何应对这种“多维度的变化”？如何利用面向对象的技术来使得该类型能够轻松的沿着多个方向进行变化，而又不引入额外的复杂度？这就要使用Bridge模式。桥梁模式是一个非常有用的模式，也是比较复杂的一个模式。熟悉这个模式对于理解面向对象的设计原则，包括"开－闭"原则(OCP)以及组合/聚合复用原则(CARP)都很有帮助。理解好这两个原则，有助于形成正确的设计思想和培养良好的设计风格。意图将抽象部分与实现部分分离，使它们都可以独立的变化。[GOF 《设计模式》],这里的抽象和实现并不一定是同一层次的概念，例如 阅读全文
摘要：
概述在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。一个软件系统常常要求在某一个对象的状态发生变化的时候，某些其它的对象做出相应的改变。做到这一点的设计方案有很多，但是为了使系统能够易于复用，应该选择低耦合度的设计方案。减少对象之间的耦合有利于系统的复用，但是同时设计师需要使这些低耦合度的对象之间能够维持行动的协调一致，保证高度的协作（Collab 阅读全文
摘要：
概述在面向对象的软件设计中，我们经常会遇到一类集合对象，这类集合对象的内部结构可能有着各种各样的实现，但是归结起来，无非有两点是需要我们去关心的：一是集合内部的数据存储结构，二是遍历集合内部的数据。面向对象设计原则中有一条是类的单一职责原则，所以我们要尽可能的去分解这些职责，用不同的类去承担不同的职责。Iterator模式就是分离了集合对象的遍历行为，抽象出一个迭代器类来负责，这样既可以做到不暴露集合的内部结构，又可让外部代码透明的访问集合内部的数据。为什么要写但现在C#的Foreach in己经替代了迭代器模式的功能,但是作为学习设计模式来说,还是很有好处的.意图提供一种方法顺序访问一个聚合 阅读全文
摘要：
概述在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法确相对稳定。如何应对这种变化？如何提供一种“封装机制”来隔离出“复杂对象的各个部分”的变化，从而保持系统中的“稳定构建算法”不随着需求改变而改变？这就是要说的建造者模式。本文通过现实汽车生产中的例子，来诠释建造者模式。意图将一个复杂的构建与其表示相分离，使得同样的构建过程可以创建不同的表示。<Design Pattern>Builder模型图通俗讲解：Builder模式的理解 建造者（Builder 阅读全文
摘要：
概述在软件系统中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合，比如要对行为进行“记录、撤销/重做、事务”等处理，这种无法抵御变化的紧耦合是不合适的。在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行为抽象为对象，可以实现二者之间的松耦合。这就是本文要说的Command模式。意图将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。[GOF 《设计模式》]结构图<Design Pattern>Command模式结构图如下：图1 Command模式结构图西游记中例子:玉帝传美猴王上天 命令 阅读全文
摘要：
概述允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它所属的类。意图 状态模式主要解决的是当控制一个对象状态装换的条件表达式过于复杂时的情况。把状态的判断逻辑转移到表示不同状态的一系列类中，可以把复杂的判断逻辑简单化。 当一个对象行为取决于它的状态，并且它必须在运行时刻根据状态改变它的行为时，就可以考虑使用状态模式了。 <Design Pattern>State模式结构图 示例关系图 描述: 一年有12个月,有四个季度,每个月都有一属于一个季度,根据月份得到这个季度的天气信息.可以用State模式来实现. 关系图: 代码设计:先创建接口IQuarter.cs:vie 阅读全文
摘要：
概述在软件系统中，有些对象有时候由于跨越网络或者其他的障碍，而不能够或者不想直接访问另一个对象，如果直接访问会给系统带来不必要的复杂性，这时候可以在客户程序和目标对象之间增加一层中间层，让代理对象来代替目标对象打点一切。这就是本文要说的Proxy模式。意图代理（Proxy）模式给某一个对象提供一个代理，并由代理对象控制对原对象的引用。 代理模式的英文叫做Proxy或Surrogate，中文都可译成"代理"。所谓代理，就是一个人或者一个机构代表另一个人或者另一个机构采取行动。在一些情况下，一个客户不想或者不能够直接引用一个对象，而代理对象可以在客户端和目标对象之间起到中介的作 阅读全文
摘要：
概述 在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。那么如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？这就是本文要说的Adapter 模式。 意图 将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 结构图 图1 类的Adapter模式结构图 图2 对象的Adapter模式结构图 生活中的例子 适配器模式允许将一个类的接口转换成客户期望的另一个接口，使得原本由于接口不兼容而不能一起工作的类可以 阅读全文
摘要：
概述 在软件系统中，有时候面临的产品类是动态变化的，而且这个产品类具有一定的等级结构。这时如果用工厂模式，则与产品类等级结构平行的工厂方法类也要随着这种变化而变化，显然不大合适。那么如何封装这种动态的变化？从而使依赖于这些易变对象的客户程序不随着产品类变化？ 意图 在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。如何应对这种变化？如何向“客户程序（使用这些对象的程序）”隔离出“这些易变对象” ，从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变？<Design Pattern>示例图 阅读全文