习惯就好zz的专栏

变化是复用的天敌！面向对象设计最大的优势在于：抵御变化。重新认识面向对象理解隔离变化从宏观层面来看，面向对象的构建方式更能适应软件的变化，能将变化所带来的影响减为最小。各司其职从微观层面来看，面向对象的方式更强调各个类“责任”。由于需求变化导致的i性能增类型不应该影响原来类型的实现----是所谓各负其责。对象是什么？从语言实现层面来看，对象封装了代码和数据。从规格层面讲，对象是一系列可被使用的公共接口。从概念层面讲，对象是某种拥有责任的抽象。面向对象设计原则（1）依赖倒

UML的基本单元一个图标表示一个class，有类的名字，加减号是共有或私有的，它包含一些属性和一些方法。

设计模式总结一个目标：管理变化，提高复用。两种手段： 分解 vs 抽象八大原则依赖倒置原则（DIP）开放封闭原则（OCP）单一职责原则（SRP）Liskov替换原则（LSP）接口隔离原则（ISP）对象组合由于类继承封装变化点面向接口编程重构技法静态 -> 动态早绑定 -> 晚绑定继承 -> 组合编译时依赖 -> 运行时依赖紧耦合 -> 松耦合什么时候不用模式代码可读性很差时需求理解还很浅时变化没有显现时不是系统的关键依赖

“领域规则”模式在特定领域中，某些变化虽然频繁，但可以抽象为某种规则。这时候，结合特定领域，将问题抽象为语法规则，从而给出在该领域下的一般性解决方案。典型模式Interpreter动机（Motivation）在软件构建过程中，如果某一特定领域的问题比较复杂，类似的结构不断重复出现，如果使用普通的编程方式来实现将面临非常频繁的变化。在这种情况下，将特定领域的问题表达为某种语法规则下的具体，然后购进啊一个解释器来解释这样的句子，从而达到解决问题的目的。模式定义给定一个语言，定义它的

Visitor访问器“行为变化”模式在组件地构建过程中，组件行为地变化经常导致组件本身剧烈地变化。“行为变化”模式将组件地行为和组件本身进行解耦，从而支持组件行为地变化，实现两者之间地松耦合。典型模式CommandVisitor动机（Motivation）在软件构建过程中，由于需求的改变，某些类层次结构中常常需要增加新的行为（方法），如果直接在基类中做这样的更改，将会给子类带来很法中的更变负担，甚至破坏原有设计。如何在不更改类层次结构的前提下，在运行时根据需要透明地为类层级结构上

Command命令模式“行为变化”模式在组件地构建过程中，组件行为地变化经常导致组件本身剧烈地变化。“行为变化”模式将组件地行为和组件本身进行解耦，从而支持组件行为地变化，实现两者之间地松耦合。典型模式CommandVisitor动机（Motivation）在软件构建过程中，“行为请求者”与“行为实现者”通常呈现一种“紧耦合”。但在某些场合——比如需要对行为进行“记录、撤销/重（undo/redo）、事务”等处理，这种无法抵御变化地紧耦合是不合适地。在这种情况下，如何将“行为请求

Chain of Resposibility 职责链“数据结构”模式常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件地复用。这时候，将这些特定数据结构封装在内部，在外部提供统一地接口，来实现特定数据结构无关地访问，是一种行之有效地解决方案。典型模式CompositeIteratorChain of Resposibility动机（Motivation）在软件构建过程中，要给请求可能被多个对象处理，但是每个请求在运行时只能有一个接收者，

Iterator迭代器“数据结构”模式常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件地复用。这时候，将这些特定数据结构封装在内部，在外部提供统一地接口，来实现特定数据结构无关地访问，是一种行之有效地解决方案。典型模式CompositeIteratorChain of Resposibility动机（Motivation）在软件构建过程中，集合对象内部结构常常变化各异。但对于这些集合对象，我们希望在不暴露其内部结构的同时，可以让外部客

Composite组合模式“数据结构”模式常常有一些组件在内部具有特定的数据结构，如果让客户程序依赖这些特定的数据结构，将极大地破坏组件地复用。这时候，将这些特定数据结构封装在内部，在外部提供统一地接口，来实现特定数据结构无关地访问，是一种行之有效地解决方案。典型模式CompositeIteratorChain of Resposibility动机（Motivation）软件在某些情况下，客户代码过多地依赖于对象容器复杂地内部实现结构，对象容器内部实现结构（而非抽象接口）地变化将

Memento备忘录模式“状态变化”模式在组件构建过程中，某些对象的状态进场面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？“状态变化”模式为这一问题提供了一种解决方案。典型模式StateMemento动机（motivation）在软件构建过程中，某些对象地状态在转换过程中，可能由于某种需要，要求程序能够回溯到对象之前处于某一点时的状态。如果使用一些共有接口来让其他对象得到对象的状态，便会暴露对象的细节实现。如何实现对象状态的良好保存与恢复？但同时又不会因此破坏

State状态模式“状态变化”模式在组件构建过程中，某些对象的状态进场面临变化，如何对这些变化进行有效的管理？同时又维持高层模块的稳定？“状态变化”模式为这一问题提供了一种解决方案。典型模式StateMemento动机（motivation）在软件构建过程中，某些对象的状态如果改变，其行为也会随之而发生变化，比如文档处于只读状态，其支持的行为和读写状态支持的行为就可能完全不同。如何在运行时根据对象的状态来透明地更改对象地行为？而不会为独享操作和状态转化之间引入紧耦合？模式定义

Mediator中介者“接口隔离”模式在组件构建过程中，某些接口之间直接地依赖常常会带来很多问题、甚至根本无法实现。采用添加一层简介（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。典型模式FacadeProxyAdapterMediator动机（Motivation）在软件构建过程中，经常会出现多个对象互相关联交互的情况，对象之间常常会维持一种复杂的引用关系，如果遇到一些需求的更改，这种直接的应用关系将面临不断地变化。在这种情况下，我们可使用一个“中介对象”来

适配器模式“接口隔离”模式在组件构建过程中，某些接口之间直接地依赖常常会带来很多问题、甚至根本无法实现。采用添加一层简介（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。典型模式FacadeProxyAdapterMediator动机在软件系统中，由于应用环境的变化，常常需要将“一些现存的对象”放在新的环境中应用，但是新环境要求的接口是这些现存对象所不满足的。如何应对这种“迁移的变化”？如何既能利用现有独享的良好实现，同时又能满足新的应用环境所要求的接口？模

Proxy代理模式“接口隔离”模式在组件构建过程中，某些接口之间直接地依赖常常会带来很多问题、甚至根本无法实现。采用添加一层简介（稳定）接口，来隔离本来互相紧密关联的接口是一种常见的解决方案。典型模式FacadeProxyAdapterMediator动机Motivation在面向对象系统中，有些对象由于某些原因（比如对象创建的开销很大，或者某些操作需要安全控制，或者需要进程外的访问等），直接访问会给使用者、或者系统接口带来很多麻烦。如何在不是去透明操作对象的同时来管理、控制

Facade 门面模式“接口隔离”模式在组件构建过程中，某些接口之间直接的依赖常常会带来很多问题、甚至根本无法实现。采用添加一层==间接（稳定）==接口，来隔离本来互相紧密关联的接口时一种常见的解决方案。典型模式FacadeProxyAdapterMediator系统间耦合的复杂度动机（motivation）上述A方案的问题在于组件的客户和组件中各种复杂的子系统有了过多的耦合，随着外部客户程序和各子系统的演化，这种过多的耦合面临很多变化的挑战。如何简化外部客户程序和系统间

Flyweight享元模式“对象性能”模式面向对象很好地解决了“抽象”地问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。典型模式SingletonFlyweight动机（Motivation）在软件系统采用存粹的对象方案的问题在于大量细粒度的对象会很快充斥在系统中，从而带来很高的运行时的代价——主要之内存需求方面的代价。如何在避免大量细粒度对象问题的同时，让外部客户程序仍然能够透明地使用面向对

“对象性能”模式面向对象很好的解决了“抽象”的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。典型模式SingletonFlyweightSingleton单件模式动机（Motivation）在软件系统中，经常有这样的一些特殊的类，必须保证它们在系统中只存在一个实例，才能确保它们的逻辑正确、以及良好的效率。如何绕过常规的构造器，提供一种机制来保证一个类只有一个实例？这应该是类设计者的责任，而不

“对象创建”模式通过“对象创建” 模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。典型模式Factory MethodAbstract FactoryPrototypeBuilderBuilder构建器动机（Motivation）在软件系统中，有时候面临着“一个复杂对象”的创建工作，其通常由各个部分的子对象用一定的算法构成；由于需求的变化，这个复杂对象的各个部分经常面临着剧烈的变化，但是将它们组合

Prototype 原型模式“对象”创建模式通过“对象创建”模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。典型模式Factory MethodAbstract FactoryPrototypeBuilder动机（Motivation）在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。如何应对这种变化？如何向

Abstract Factory 抽象工厂“对象创建”模式通过“对象创建” 模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。典型模式Factory MethodAbstract FactoryPrototypeBuilder动机（Motivation）在软件系统中，经常面临着“一系列相互依赖的对象”的创建工作；同时，由于需求的变化，往往存在更多系列对象的创建工作。如何应对这种变化？如何绕过常规的对象创

“对象创建” 模式通过“对象创建” 模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。典型模式Factory MethodAbstract FactoryPrototypeBuilder动机（Motivation）在软件系统中，经常面临着创建对象的工作；由于需求的变化，需要创建的对象的具体类型经常变化。如何应对这种变化？如何绕过常规的对象创建方法(new)，提供一种“封装机制”来避免客户程序和这种“

桥模式“单一职责”模式：在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类极具膨胀，同时充斥着重复代码，这时候的关键时划清责任。典型模式DecoratorBridge动机（Motivation）由于某些类型的固有的实现逻辑，使得它们具有两个变化的维度，乃至多个纬度的变化。如何应对这种“多维度的变化”？如何利用面向对象技术来使得类型可以轻松地沿着两个乃至多个方向变化，而不引入额外的复杂度？模式定义将抽象部分(业务功能)与实现部分(平台实现)

装饰模式“单一职责”模式：在软件组件地设计中，如果责任划分地不清晰，使用继承得到的结果往往是随着需求地变化，子类极具膨胀，同时充斥着重复代码，这时候地关键是划清责任。典型模式DecoratorBridge动机（Motivation）在某些情况下我们可能会“过度地使用继承来扩展对象地功能”，由于继承为类型引入地静态特质，使得这种扩展方式缺乏灵活性；并且随着子类地增多（扩张功能地增多），各种子类地组合（扩张功能地组合）会导致更多子类地膨胀。如何使“对象功能的扩展”能够根据需要来动态地

“组件协作”模式：现代软件专业分工之后第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。典型模式Template MethodStartegyObserver / Event动机（Motivation）在软件构建过程中，我们需要为某些对象建立一种“通知依赖关系”——一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知。如果这样的依赖关系过于紧密，将使软件不能很好地抵御变化。使用

“组件协作”模式：现代软件专业分工之后第一个结果是“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。典型模式Template MethodStartegyObserver / Event动机（Movivation）在软件构建过程中，某些对象使用的算法可能多种多样，经常改变，如果将这些算法都编码到对象中，将会是对象变得异常复杂；而且有时候支持不使用的算法也是一个性能负担。如何在运行时根据需要透明地更改对象的算法？将

重构书籍《重构-----改善既有代码的设计》《重构与设计 Recfactoring to Patterns》重构关键技法静态 -> 动态早绑定 -> 晚绑定继承 -> 组合编译时依赖 -> 运行时依赖紧耦合 -> 松耦合“组件协作”模式：现代软件专业分工之后的第一个结果时“框架与应用程序的划分”，“组件协作”模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。典型模式Template MethodStartegyO

##1.什么是设计模式“每一个模式描述了一个在我们周围不断重复发生着的问题，以及该问题的解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复劳动“----Christopher Alex2.GOF设计模式书籍：历史性著作《设计模式：可复用面向对象软件的基础》3.从面向对象说起底层思维：向下，如何把握机器底层从微观理解对象构造语言转换、编译转换、内存模型、运行时机制。三大面向对象机制：封装，隐藏内部实现继承，复用现有代码多态，改写对象行为抽象思维：向上，如何将我们周围世