日月 的专栏

【动机】        绕过常规构造函数，通过某种机制，使一个类只有一个实例【核心】        如何控制客户对构造函数的任意调用【代码实例】// 无参数的Singleton实现public class Singleton{    public static readonly Singleton g_Instance = new Singleton() ;    private Singleton() { }    // 类的封装    // ... ...}// 带参数的Singleton实现publi

【起源】         对于某项工作，有稳定的整体操作结构，但每个子步骤是经常变化的。需要应对子步骤的变化，提炼整体操作结构。【动机】         定义一个操作中的算法骨架，而将具体步骤的实现延迟到子类中。【核心】         类继承：合理分工，父类“定义子步骤的名称”和“调用子步骤构建稳定算法”，子类通过重写“实现子步骤的具体操作”。         这个过程又叫做“晚绑定”。【代码实例】// 工人（程序框架）public abstract class Worker{ prote

【起源】         多个对象互相关联交互的情况，在对象间须维持复杂的引用关系，不容易应对变化；         创建一个“中介对象”来关联对象间的关联关系，任意两个对象之间不用直接通信，它们通过“中介对象”来通信。         耦合降低，更容易应对变化。【动机】         用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示的相互引用，从而使其耦合松散，而且可以独立的改变它们直接的交互。【核心】         将多个对象的行为集中封装到“中介对象”中，各个对象就是“中介对象”的注

【起源】         我们希望封装集合对象的内部结构，同时让客户代码透明的访问集合内部的子元素。         将“透明遍历”作为一种算法抽象出来，任何集合对象都可实现，它被叫做迭代器。【动机】         提供一种方法顺序访问一个聚合对象中的各个元素，而又不暴露该对象的内部表示。【核心】         1.迭代器内三个重要的方法(IEumerator)         2.聚合对象提供迭代器(IEnumerable)         3.Client利用这三个方法实现“透明遍历”：      

【起源】         程序关注对象的状态，希望保存某些状态点，并随时恢复（相当于数据库备份还原）。【动机】         在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，于是可以随时将对象恢复到这个状态。【核心】         提供一个Memento类，随时对所关注的对象做“镜像”，方便对象恢复到之前的某个状态。         Memento的职责是保存“镜像”。         被关注对象提供备份和还原方法，与Memento对象衔接。【代码实例】【模型图】

【起源】         某个对象的行为，可以用多种算法实现，因此考虑将算法单独封装出来（利于算法维护），在创建对象时再指定具体算法。【动机】         定义一系列算法，把它们一个个封装起来，并且使它们可相互替换。该模式使得算法可独立于使用它的客户而变化。【核心】         对象组合的使用。         与Bridge模式很像，但Bridge关注的是“由谁来实现”；Strategy关注的是“用哪种方式实现”；         使用时，首先提炼会变化的算法，抽象出接口；然后将具体算法实现单独封

【起源】         对象处于不同的状态会拥有不同的行为，并且状态之间互相切换，就像数字电路里的状态机。         在结构化编程中，用switch来实现，先判断状态，然后根据输入去做操作，在合适的地方做状态切换。         状态间的切换被写死了，并且不利于扩展状态。         现在希望用面向对象的方式，使对象的切换变得灵活，并且扩展状态比较方便，在宏观上希望看起来就是一个对象。【动机】         允许一个对象在其内部状态改变时，改变它的行为。从而使对象看起来似乎修改了其行为。【核

【起源】         需要在对象之间建立“通知依赖关系” —— 一个对象发出消息，所有依赖对象收到通知。         希望最好的效果是 “消息耦合对象的处理”，而不是 “消息耦合对象”。【动机】         定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。【核心】         以两个角色为研究对象：                       “被观察者”做2件事：1.检测状态改变 2.发出消息；                   

【起源】         一个请求需要被多个对象中的一个处理，但不知道是哪一个。         结构化的做法是用if...else... ，即将请求与处理对象的映射关系硬编码。         希望找到一种方法，使映射关系灵活变化，即对请求和处理对象解耦。【动机】         使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递请求，直到有一个对象处理它为止。【核心】         对于某个处理对象：1.检查是否可处理请求 2.可以就处理 3

【起源】         类的层次结构稳定，但同一rank上的类的行为不稳定（随时需要扩展），将需要扩展的方法隔离封装出来，就是Visitor模式。【动机】         表示一个作用于某个对象结构中的各元素的操作。它可以在不改变各元素类的前提下，定义作用于这些元素的新操作。【核心】         抽象类/接口           类1   类2   类3   。。。             方法1             方法2             方法3             。。。    

【目的】         Teplate Method: 稳定结构，替换具体步骤         Command: 行为静态化，把 “对象.方法” 封装成对象实体         Interpreter: 重复出现的复杂问题（可以分解成有限的细小问题），定义解释器（分解大问题，解决小问题）和描述方式         Mediator: 多个对象协同工作，把协同的部分封装出来，交给中介对象协调完成         Iterator: 专门为集合对象提供的“透明遍历子对象方法”（.net用IEnumerable

【创建型模式】：在创建对象时，根据具体变化情况，对new操作进行封装，实现创建过程的复用                    Singleton: 解决 “对象个数” 问题                    Factory Method: 解决 “某个类的子类个数变化” 问

通过回答几个问题来了解《设计模式》的概念。 什么是经验？       经历了一个问题，摸索出解决方法，验证后正确，总结出“经验”。记录下来，下次碰到此问题，复用此解决方法。       优点：少碰钉子，省去重复劳动，节省时间       本质：键值对【问题，解决方法】       过程：面对一个问题，通过实践各种可能性，总结出正确的解决方法；记录此【问题，解决方法】键值对

【起源】         一种特定类型的问题，发生的频率足够高，问题不断变化但有规律可循。可以考虑将问题用一个句子描述（语法自定义），并构建解释器（描述语法规则），解释句子的含义（处理该问题）。【动机】         给定一个语音，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。【核心】         宏观思想：映射。         任何一种语言的本质：含义的表达。“语言的表示”与“含义”是映射关系，通过“语法规则”这座桥梁联系起来。         Interpre

【目的】         Adapter: 重新包装已有的类，进行接口转换（通过对象组合，复用已有的类）         Bridge:  将“实现”封装到组合类中，分离“抽象”与“实现”（通过类继承，可以沿着两个方向变化）         Composite: 让集合类实现基本类的行为，使集合对象和单个对象的使用具有一致性           Decorator: 通过重写指定对象的行为，增加它的职责，即动态的给一个对象增加额外职责         Facade: 封装要使用到的子系统中的部分功能，向Cl

【起源】         client 在创建对象时 依赖于 class， class 的变化会对 client 造成影响，因此要封装 创建对象的过程；         通常使用的方式：新建工厂类，用静态方法封装 对象的创建过程；【动机】         提供一个接口，用来创建 一系列相互依赖的对象（存在多个系列的对象，在不同系列中切换）；         封装 系列（纵向） 这个变化，抽象类（横向）的变化 在后面的模式中解决；                抽象类A       抽象类B        .

【起源】         一个复杂的对象，需要通过 各个子对象 按照 固定算法 构成；         需求的变化点是 各个子对象，组合算法 相对稳定；【动机】         将一个复杂对象的 构建与表示 分离，使得同样的构建过程可以创建不同的表示；Client      Director(组合算法)       Builder(创建子对象)       基本类

【起源】         某个类经常变化，但是接口保持稳定；【动机】         定义一个用于创建对象的接口，让子类决定实例化哪一个类；         （用抽象类实现稳定的部分，变化的部分由子类重写；每个类的对象创建工作由一个对应的类来完成，称之为“工厂类”）   Client      AbstractFactory      AbstractClass                       Factory1                   Class1                  

【起源】         结构复杂的对象，接口稳定，内容经常发生变化；【动机】         使用原型实例指定创建对象的种类，然后通过 复制 这些原型来创建新的对象；【核心】         与 Factory Method 相似，可看成 工厂和实体类耦合到了一起，把 Prototype 当成工厂用就行了；         差别是 Prototype 创建的对象是对原型的复制，即已经初始化，而 Factory Method 创建的是新对象，需要重新初始化；【代码实例】// Prototype（抽象出类的原

【目的】         创建型模式解决 与“对象创建”相关 的问题。【相似点和不同点】         一。Singleton解决 如何限制“对象个数”问题； Prototype, Fatory Method, Abstract Factory, Builder解决“单独封装创建过程”问题。         二。Singleton, Prototype都将“创建过程”集成到了类的内部； Factory Method, Abstract Factory, Builder都用一系列工厂类“封装创建过程”。  

【适配的概念】         在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。         旧接口 ---> Adapter ---> 新接口【起源】         “旧的对象和接口”在以前的环境下运行良好，由于环境发生变化，旧的接口已不能适应，但仍想复用旧的对象；         目标：以“旧的对象”为基础，构造一个新类，实现“新的接口”。【动机】         将一个类的接口转换为客户希望的另一个接口。使得原本由于接口不兼容而不能一起工作的那些类，可以一起工作。【代码实例】//

【起源】         某类型有多个变化维度（比如：有才的男人。才华和性别是两个维度），目标是：不引入额外的复杂度，轻松的适应两个方向的变化。【动机】         将抽象部分与实现部分分离，使他们可以独立的变化。【核心】         对抽象类和子类的理解：            1.通常的理解方式：子类是抽象类的具体情况，即：子类是强修饰的抽象类（如：人和男人）。用作“主语”。相当于“实现部分”。            2.抽象类是枚举变量，子类是枚举值。用作“定语”来弱修饰“

【起源】         递归的对象组合（如：树木，树林，森林），对容器对象的操作需要递归到基本对象上，因此Client程序在处理时，需要判断是容器对象还是基本对象，并分别处理。         如何让Client不关注容器对象的内部结构，既然容器对象和基本对象实现同样的接口，就让容器对象的处理与基本对象一样。【动机】         将对象组合成树形结构，以表示“整体 - 部分”的层次结构。         Composite使得用户对单个对象和组合对象的使用具有一致性。【核心】         容器对象

【起源】         不改变原始类，动态的给某个对象增加一种或多种功能。         比如：公交车有运送功能，想给它添加“无人售票”或“自动报站”功能；不同路线的公交车，添加的功能是这两个功能的排列组合；其实是在原有“运送功能”的基础上，把“额外功能”添加上；         本质：重写对象行为，添加额外功能。【动机】         动态的给一个对象增加一些额外职责。【核心】         1.给一个类增加功能，可以通过继承重写该类的方法，在原有方法的基础上，加上新的方法；但是带来一个问题，新加

【动机】         运用共享技术有效的支持大量细粒度对象。目的是减少内存消耗。【核心】         面向对象解决了抽象性问题，但是没有考虑机器在运行时的代价。Flyweight模式是为了降低系统中对象的个数。         算法很简单：如果已经存在，就直接返回；不存在，就创建新对象，并返回；【代码实例】【模型图】

【起源】         Client需要使用 一个复杂的子系统（包含很多类），并且该系统在不断的改进。因此Client必须详细了解子系统的每个细节，然后才能投入使用（Client与子系统的耦合很深）。这需要耗费巨大的精力，如何使Client更轻松？答案是让Client只了解完成任务必须的相关部分，这就是Facade模式。【动机】         为子系统中的一组接口提供一个一致的界面，让子系统更加容易使用。【核心】         将一组耦合性很强的接口单独封装到一个类中，提供给Client使用。（很简单

【起源】         某些对象的直接访问会给Client带来麻烦，并且使系统结构复杂。         比如：数据访问层 就是一个数据库代理，使业务层不用关注数据库的表结构，而且使系统结构清晰。【动机】         为其它对象提供一种代理以控制对这个对象的访问。【核心】         增加一层间接层，处理复杂问题，然后暴露简单的接口。【代码实例】// 招聘员工public interface IEmployment{ public void Employ(); // 招聘员工

【起源】         耦合存在于实体对象之间，也存在于实体对象与行为之间。         通常的方法调用，“行为请求者”和“行为实现者”之间呈现紧耦合。但在某些场合（如：需要对对行为进行“记录，undo/redo，事务”操作），需要松耦合。此时，将行为抽象为Command对象，置于“行为请求者”和“行为实现者”之间，使两者都依赖于Command对象。【动机】         将一个请求封装为一个对象，从而使你可用不同的请求对Client进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作。