甜心奶酪的专栏

主要解决紧耦合的问题。不要实现紧耦合，而要实现松耦合。1、动机在软件系统中，经常面临着“某个对象”的创建工作；由于需求的变化，这个对象经常面临着剧烈的变化，但是它却拥有比较稳定的接口。如何应对这种变化？如何提供一种“封装机制”来隔离出“这个易变对象”的变化，从而保持系统中“其他依赖该对象的对象”不随着需求改变而改变。2、意图定义一个用于创建对象的接口，让子类决定实例化哪一个类，Fa

某些对象请求的接受者可能多种多样，变化无常 1、动机在软件构建过程中，一个请求可能被多个对象处理，但是每个请求在运行时只能有一个接受者，如果显式指定，将必不可少地带来请求发送者与接受者的紧耦合。如何使请求的发送者不需要指定具体的接受者？让请求的接受者自己在运行时决定来处理请求，从而使两者解耦。2、意图使多个对象都有机会处理请求，从而避免请求的发送者和接受者之前的耦合关系。将这些对象连成一条

对象状态的回溯对象状态的变化无端，如何回溯/恢复对象在某个点的状态?1、动机在软件构建过程中，某些对象的状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某个点时的状态。如果使用一些公有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。如何实现对象状态的良好保存与恢复？但同时又不会因此而破坏对象本身的封装性。2、意图在不破坏封装性的前提下，捕获一个对象的内部状态，

对象状态影响对象行为对象拥有不同的状态，往往会行使不同的行为...1、动机在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化。比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象的行为？而不会为对象操作和状态转化之前引入紧耦合？2、意图允许一个对象在其内部状态改变时改变它的行为。从而使对象看起来似乎修改了其行为

对象可能经常需要使用多不同的算发，但是如果变化频繁，会将类型变得脆弱...1、动机在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会使对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。如何在运行时根据需要透明地更改对象的算法？将算法与对象本身解耦合，从而避免上述问题？2、意图定义一系列算法，把它们一个个封装起来，并且使它们

 类层次结构的变化类层次结构中可能经常由于引入新的操作，从而将类型变得脆弱...1、动机在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很繁重的变更负担，甚至破坏原有设计。如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层次结构上的各个类动态添加新的操作，从而避免上述问题？2、意图表示一个作用于某对象

创建型模式：(1) Sigleton模式解决的是实体对象个数的问题。除了Sigleton之外，其他创建型模式解决的都是new所带来的耦合管理。(2) Factory Method,Abstract Factory , Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。(3) 如果遇到“易变类”，起初的设计通常从Fa

开-闭原则(OCP)：一个软件实体应当对扩展开放，对修改关闭。里氏代换原则(LSP)：一个软件实体如果使用的是一个基类的话，那么一定适用于其子类，而且它根本不能察觉出基类对象和子类对象的区别。 依赖倒转原则(DIP)：要依赖于抽象，不要依赖于具体。接口隔离原则(ISP)：使用多个专门的接口比使用单一的总接口要好。合成/聚合复用原则(CARP)：要尽量使用合成/聚合，尽量不要使用继承。迪米特法则(L

无处不在的Template Method，如果你只想掌握一种设计模式，那么它就是Template Method。变与不变变化……是软件设计的永恒主题，如何管理变化带来的复杂性？设计模式的艺术性和复杂度就在于如何分析，并发现系统中的变化点和稳定点，并使用特定的设计方法来应对这种变化。1、动机在软件构建过程中，对于某一项任务，它常常有稳定的整体操作结构，但各个子步骤却有很多改变的需求，或者由于

耦合与变化耦合是软件不能抵御变化灾难的根本性原因，不仅实体对象与实体对象之间存在耦合关系，实体对象与行为操作之间也存在耦合关系。1、动机在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种紧耦合。但在某些场合——比如需要对行为进行“记录、撤消/重做（undo/redo）、事务”等处理，这种无法抵御变化的紧耦合是不合适的。 在这种情况下，如何将“行为请求者”与“行为实现者”解耦？将一组行

1、动机在软件构建过程中，如果某一特定领域的问题比较复杂，类似的模式不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化，在这种情况下，将特定领域的问题表达为某种语法规则下的句子，然后构建一个解释器来解释这样的句子，从而达到解决问题的目的。2、意图给定一个语言，定义它的文法的一种表示，并定义一种解释器，这个解释器使用该表示来解释语言中的句子。3、图 4、代码pub

依赖关系的转化多对多的关系 --> 多对一的关系1、动机在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的引用关系将面临不断的变化。在这种情况下， 我们可以使用一个“中介对象”来管理对象间的关联关系，避免相互交互的对象之间的紧耦合引用关系，从而更好地抵御变化。2、意图用一个中介对象来封装一系列的对象交互。中介

发布-订阅模型 1、动机在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，如果这样的依赖关系过于紧密，将使软件不能很好得抵御变化。2、意图定义对象间的一种一对多的依赖关系，以便当一个对象的状态发生改变时，所有依赖于他的对象都得到通知并自动更新。3、图4、代码public clas

直接与间接人们对于复杂的软件系统常常有一种处理手法，即增加一层间接层，从而对系统获得一种更为灵活，满足特定需求的解决方案。1、动机在面向对象系统中，有些对象由于某种原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统结构带来很多麻烦。如何在不失去透明操作对象的同时来管理/控制这些对象特有的复杂性？增加一层间接层是软件开发中常见的

面向对象的代价面向对象很好地解决了系统抽象性的问题，同时在大多数情况下，也不会损及系统的性能。但是，在某些特殊的应用中下，由于对象的数量太大，采用面向对象会给系统带来难以承受的内存开销。比如图形应用中的图元等对象、字处理应用中的字符对象等。1、动机采用纯粹对象的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时代价——主要指内存需求方面的代价。 如何在避免大量细粒度对象问题的

 具体套用的模版就是：工厂类publict class Creator{         public static Product factory()         {                       return new ConcreteProduct();         }}抽象产品类public interface Product

1、动机：       必须保证系统中只有一个实例。是应该类设计者负责，还是使用者来负责呢？应该归属给类的设计者。如何饶过常规的构造器，提供一种机制来保证一个类只有一个实例。 精神：如何控制用户使用new对一个实例构造器的任意调用。2、意图保证一个类仅有一个实例，并提供一个该实例的全局访问点。3、图4、代码实现单线程Singleton实现，可以使用参数的。即懒汉式实现方法。

Sigleton模式解决的是实体对象个数的问题。除了Sigleton之外，其他创建型模式解决的都是new 带来的耦合关系。Factory Method,Abstract Factory , Builder 都需要一个额外的工厂类来负责实例化“易变对象”，而ProtoType则是通过原型（一个特殊的工厂类）来克窿易变对象。如果遇到“易变类”，起初的设计通常从Factory Method开始，

House有几个部分构成的，可能有5、6个墙壁。有屋顶，可能有门。每一个房屋的变化，都将导致房屋构建的重新修正。相对稳定的：房子的构建是相对稳定的。1、动机：在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合在一起的算法却相对稳定。 如何应对这种变化？如何提供一种“封

问题的提出：new 的问题常规的对象创建方法Road road = new Road();实现依赖，不能应对“具体实例化类型”的变化解决思路封装变化点：哪里变化，封装哪里；不是变化就不要封装。面向接口编程，依赖接口，而非依赖实现简单的实现方式：//Road为抽象类，返回的是具体的类class RoadFactory{ public Static Road CreateRoad() 

要解决的问题 ：依赖倒置原则：高层不应该依赖于低层模块，二者应该依赖于抽象;抽象不应该依赖于实现细节，实现细节应该依赖于抽象。抽象A直接依赖于实现细节B  ---> 抽象A依赖于抽象B，实现细节B依赖与抽象B1、动机在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它却拥有比较稳定一致的接口。如何应对这种变化？如何向“客户程

 适配，即在不改变原有实现的基础上，将原先不兼容的接口转换为兼容的接口。1、动机在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。 如何应对这种“迁移的变化”？如何既能利用现有对象的良好实现，同时又能满足新的应用环境所要求的接口？2、意图将一个类的接口转换成客户希望的另一个接口。Adapter模式使得原本由于

 依赖倒置原则抽象B是相对稳定的，实现细节B是相对变化的。如果抽象B也不稳定，也会变化，怎么办？假如我们需要一个支持PC和手机的坦克游戏，在PC上和手机上功能都一样。都有同样的类型，面临同样的需求功能变化，比如坦克可能有不同种的型号，T50 ，T75，T90......对于其中的设计，我们很可能很容易地设计出来一个Tank的抽象类，然后不同类型的Tank继承自该类。public a

 对象容器的问题 public interface IBox{ public void Process();}public class SigleBox : IBox{ public void Process(){...}}public class ContainBox : IBox{ public void Process(){...} public ArrayList getBoxes()

子类复子类，子类何其多public abstract class Tank{ public abstract void Run(); public abstract void Shot(); public abstract void Thun();}public class T50 : Tank{...}public class T50A : Tank,IA{...}public cl

系统的复杂度public class Wheel{ public void WAction1(); public void WAction2();}public class Engine{ public void EAction1(); public void EAction2();}public class Bodywork{ public void BAction1(); publ

集合的内部结构与外部访问1、动机在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客户代码透明地访问其中包含的元素；同时这种“透明遍历”也为“同一种算法在多种集合对象上进行操作”提供了可能。使用面向对象技术将这种遍历机制抽象为“迭代器对象”为“应对变化中的集合对象”提供了一种优雅的方式。2、意图提供一种方法顺序访问一个聚合对象中