misterdo的专栏

动机(Motivation) 客户和组件中各种复杂的子系统有过多的耦合 如何简化外部客户程序和系统间的交互接口？如何解耦？ 模式定义为子系统中的一组接口提供一个一致(稳定)的界面，Façade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用(复用)。 ——《设计模式》GoF要点总结 从客户程序角度来看，Façade模式简化了整个组件系统的接口，对于组件内部与外部的客户程序来说， 达到了一种”解耦“的效果——内部子系统的任何变化不会影响到Façade接口的变化。

动机(Motivation) 对象状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。 如何在运行时根据对象的状态来透明地改变对象的行为？ 模式定义允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为。 ——《设计模式》GoF要点总结 State模式将所有与一个特定状态相关的行为都放入一个State的子对象中，在对象状态切换时，切换相应的对象； 但同时维持State的接口，这样实现了具体操作与

动机(motivation) 在软件系统中，经常面临这“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。 如何应对这种变化？如何向“客户程序(使用这些对象的程序)”隔离出“这些易变对象”，从而使得依赖这些”易变对象“的客户程序不随着需求改变而改变。 模式定义使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。 ——《设计模式》GoF要点总结 Prototype模式同样用于隔离对象的使用者和具体类

动机(Motivation) 由于应用环境的变化，常常需要将”一些现存的对象“放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足。 如何应对这些”迁移的变化“？ 模式定义将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 ——《设计模式》GoF要点总结 在遗留代码复用、类库迁移等方面有用 非适配器模式缺点：增加个欧元（ERO）的时候，对外的接口发生了变化，代码的功能需要重新写，.

动机（Motivation） 由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度(功能类)，乃至多个纬度的变化。 如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？ 模式定义将抽象部分(业务功能)与实现部分(平台实现)分离，使它们都可以独立地变化。 ——《设计模式》GoF要点总结 Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系，使得抽象和实现可以沿着各自的维度来变化。所谓抽

动机（Motivation） 在某些情况下我们可能会“过度地使用继承来扩展对象的功能”，由于继承为类型引入的静态特质，使得这种扩展方式缺乏灵活性； 并且随着子类的增多（扩展功能的增多），各种子类的组合（扩展功能的组合）会导致更多子类的膨胀。 如何使“对象功能的扩展”能够根据需要来动态地实现？同时避免“扩展功能的增多”带来的子类膨胀问题？从而使得任何“功能扩展变化”所导致的影响将为最低？ 模式定义动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子

动机(Motivation) 在面向对象系统中，有些对象由于某种原因(比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等)， 直接访问会给使用者、或者系统结构带来很多麻烦。 如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的解决方式。 模式定义为其他对象提供一种代理以控制(隔离，使用接口)对这对象的访问。 ——《设计模式》GoF要点总结 Proxy并不一定要求保持接口完整的一致性，只要能够实现间接控制，有时

动机(Motivation) 在软件系统采用纯粹对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。 如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对象的方式来进行操作？ 模式定义运行共享技术有效地支持大量细粒度的对象的复用。 ——《设计模式》GoF要点总结 面向对象很好地解决了抽象性的问题，但是作为yield运行机器中的程序实体，我们需要考虑对象的代价问题， Flyweight主要解决面向对

动机(Motivation) 在软件系统中，经常有这样一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确性、以及良好的效率。 如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？ 这应该是类设计者的责任，而不是使用者的责任。 模式定义保证一个类仅有一个实例，并提供一个该实例的全局访问点。 ——《设计模式》GoF要点总结 Singleton模式中的实例构造器可以设置为protected以允许子类派生。 Singleton模式一

动机（Motivation） 在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系” ——一个对象（目标对象）的状态发生改变，所有的依赖对 象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。 使用面向对象技术，可以将这种依赖关系弱化，并形成一种稳定的依赖关系。从而实现软件体系结构的松耦合。 模式定义定义对象间的一种一对多（变化）的依赖关系，以便当一个对象(Subject)的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。 ——《 设计

动机（Motivation） 在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。 如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“具体对象创建工作”的紧耦合？ 模式定义定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的：解耦，手段：虚函数）到子类。 ——《设计模式》GoF要点总结 Factory Method模式用于隔离类对象

动机（Motivation） 在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。 如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦，从而避免上述问题？ 模式定义定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序(稳定)而变化（扩展，子类化）。 ——《设计模式》 GoF要点总结 Strategy及其子

动机（Motivation） 在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于固有的原因（比如框架与应用之间的关系）而无法和任务的整体结构同时实现。 如何在确定稳定操作结构的前提下，来灵活应对各个子步骤的变化或者晚期实现需求？ 模式定义定义一个操作中的算法的骨架 (稳定) ，而将一些步骤延迟 (变化) 到子类中。 Template Method使得子类可以不改变(复用)一个算法的结构即可重定义(override 重写)该算法的 某

什么是设计模式“每一个模式描述了一个在我们周围不断重复发生的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动”。 ——Christopher Alexander松耦合：降低每个模块之间的依赖关系，减少后期的修改工作量紧耦合：代码模块之间高度依赖，牵一发而动全身，不利于后期的修改设计模式使用的目的是为了管理变化、提高复用。一般在程序稳定、需要提高其复用性、扩展性的时候可以使用设计模式，刚开始的时候可以暂不考虑使用设计模式。在代...