设计模式总结

原文1：http://2710067471.iteye.com/blog/2088731

原文2：http://2710067471.iteye.com/blog/2088739

原文3：http://2710067471.iteye.com/blog/2089076

将近一个月，小编终于将设计模式学习了一边，整个过程的学习代码也已经付到了前面博客的附件中，下面就对设计模式做一个总结，仅仅写出来了一些感悟，欢迎大家留言讨论： 

首先，设计模式是一种面向对象编程的思想，学习设计模式是为了我们在设计软件时，更加能够以面向对象的方式和思维去设计软件，我个人最大的感受是“千万不要为了使用设计模式而使用设计模式”，我最近常常被人问到，什么时候使用设计模式，其实我想说“无招胜有招”。 


设计模式给我们讲的是一种理念，一种编程的原则，学了设计模式，在编程的时候，我们就要学会使用这种原则。而不是在遇到问题的时候去拼命地想我要用那种设计模式。 

当然，这并不意味着我们学完设计模式后啥也没会，其实不然，我们要知道每种模式他是在解决一个什么问题，体现了什么原则，仅此而已。好了，下面我们进入正题： 


大家都知道，面向对象的三大特征：封装继承多态。这是我们学完一门面向对象语言最基本的掌握。对于设计模式，学完之后，要知道有这些设计原则： 

单一职责原则：一个类最好只做一件事，这一原则保证了类的高内聚，同时满足单一职责原则的类一般都具有低耦合。 

开放封闭原则：一个系统要满足对修改封闭，对扩展开发。这一原则极大地体现了面向对象语言可复用的优点。 

李氏替换原则：一个类的子类必须能够替换其父类，实际上这是多态你能够实现的基本保证。 

接口隔离原则：在系统的实设计中，我们尽量使用多个小的接口代替一个大的接口，说白了，就是接口也要尽量专一，不能集合了大量的无用方法。 

依赖反转原则：高层次的模块不依赖于低层次的模块，他们都依赖于抽象。具体依赖于抽象，抽象不依赖于具体。这就要求我们要面向接口编程。 

迪米特法则：这一原则又叫做最少知识原则，他要求类与类之间的联系越少越好，最好是没有，但没有是不可能的，因此，当一个类不可避免的与另一个类联系时，我们要尽量的联系最小。 

合成/聚合复用原则：在一些情况下，继承是可以用合成。聚合来代替的，这个时候，一定要使用合成、聚合，因此基于继承的结构改变起来很困难，同时在后期维护的过程中，系统的类结构会变得异常庞大。 

以上是一些基本的面向对象的设计原则，在下面对模式的总结中，我们会看到，其实，所有的模式都是在使软件结构变得尽量的满足这些原则，仅此而已。 

第一组设计模式是创建模式，在面向对象语言中，除了用new来得到对象外，还有以下的五个结构可以让我们得到类对象：抽象工厂模式，工厂方法模式，原型模式，单例模式，建造者模式。 

这里，想再强调一下建造者模式：建造者模式也是得到类对象的一种方法，他将类的创建过程与类的表示相分离，这就使得相同的创建过程可以创建不同的类对象，但前提是这些类对象创建的过程者的相同，不然的话，建造者模式都没办法使用起来，又如何使用它来创建对象呢？ 

因此，我们说，对于一些有着相似的创建过程，而仅仅是不同的过程实现细节不同的那些类，可以考虑使用建造者模式。 

建造者模式很容易改变一个产品的内部表示，并且使得构造代码与表示代码分开，这样对于客户来说，他无需关心过程，仅仅需要告诉需要什么产品，建造者模式就会按照约定好的过程创建不同的产品给客户。 

设计模式的第二类是结构模式，他包括：代理模式，适配器模式，外观模式，享元模式，组合模式，桥接模式，装饰模式 

代理模式，适配器模式，外观模式是三个比较相似的模式，代理模式是代表一个单一对象，同时对该对象的访问必须通过代理；而外观模式是代表一个子系统，他是对子系统中的接口进行二次封装，得到一个高层次的接口，同时，对盖子形同的访问可以通过该接口，也可以不通过该接口。适配器模式是当用户使用的类实际提供的接口与用户希望使用的接口不一致时，我们通过集成用户希望的接口实现适配器模式，适配器模式更像是一个转换器。而外观模式和代理模式是真正的代理。 

享元模式是针对共享的细粒度对象，其关键在于享元池，享元池中放了每一种享元的一个实例，每次需要一个享元实例时，就到享元池中去找，如果没有，享元池会新建然后放到池里然后返回，如果有，直接返回。 

组合模式描述的是一种整体与局部的关系，同时局部有可以看成一个新的整体。 

桥接模式就是合成聚合复用原则的体现。 

装饰模式可以允许使得为单个对象添加功能变得方便。

在设计模式分类中，还有一种叫做行为模式，他们有模板模式，观察者模式，迭代器模式，解释器模式，策略模式，状态模式，职责链模式，命令模式，中介者模式，访问者模式，备忘录模式， 


首先，模板模式要求我们去合理的抽象，其实这就是面向对象语言可复用性的一个体现，将那些常用的代码抽象出来放到一个模板中，没啥好说的， 

观察者模式就是有一个被观察者，同时为他定义多个观察者，一旦被观察者有什么风吹草动，观察者们都会发现。在JAVA中已经有了实现。 

迭代器模式是我们访问集合常用的方法，也不再赘述。 

策略模式是一种很好地模式，他用合成，聚合的关系去代替类之间的继承的关系，很好的降低了类之间的耦合。使软件的可维护性很好。我们知道，通常情况下，继承于父类的子类都是重写了父类的方法，而其实他们之间的唯一的区别就是不同的子类使用的算法不同，因此策略模式让父类A拥有一个Strategy属性，对于每一种计算方法仅仅需要为类的strategy属性赋予不同的strategy子类对象，从而解决了原来的问题，同时避免了继承的出现。 

状态模式：当一个类中的判断条件过于复杂的时候，我们使用状态模式来将这些复杂的判定条件分解到不同的状态类中，这样也便于状态的增加与删除。但是一般而言，判定条件中都有一个用于判定的变量，在状态模式中，这个判定的条件作为参数在不同的状态之间传递。 

职责链模式：职责链模式是定义一系列的领导，同时每个领导又有其领导，对待每个请求，都从最小的领导开始处理，能处理就OK，处理不了，交给他的领导处理。这就是一个职责连的模式。在前面的描述中，也应该明白，要想链能正常工作，每个领导必须有其上层直接领导，这样才能保证链的正常工作。 

在策略模式，职责连模式中可以看到，策略模式让一个类动态的选择处理问题的算法成为可能，其实仅仅是在类中添加一个不同算法的抽象类的属性，通过给属性赋不同的值，从而选择不同的算法；职责连模式是每个具体的领导类都有个属性执行其直接领导，以保证链能传递下去； 

状态模式与职责连模式有些相似，不同的状态类似领导，但是你会发现，在职责连模式中，外部的内容在不同领导间传递是不变的，只有有权利处理该问题的领导才会获得并处理该内容。而在状态模式中，每个具体状态本身都会对外部的内容做一个改变。 

说白了，责任链模式在自己的类中定义自己的下一个类是谁？而状态者模式是在外部传入的类中定义自己的下一个类是谁？责任链模式的每个类都是领导，领导是自己就知道自己的上司是谁的？但状态模式的每个类是状态，状态自己是不可能知道下一个状态是啥？所以他必须依靠状态主体来记录下一个状态，而状态主体就是那个可能处于不同状态的类，在我的博客中，就是那个Light类，进入每个状态都会更改light的state属性，说白了不同状态的环境是不一样的。 

好了，往下说。。。。。 

命令模式与中介者模式差不多：命令模式试讲请求的发出者与请求的处理者分开，用一个Invoker类来接受请求并发号施令。中介者类是作为一个中介，将系统中的各个类的交互都封装在中介者中，中介者负责不同类对象之间的交互，这样减少了系统的耦合性。 

备忘录模式就是在要备忘的类中写一个方法，返回一个状态，但要注意，这个状态要new出来，不然类对象小时，状态随之消失。 

访问者模式是一种不太常用的模式，他通常用于类对象固定的那些数据结构中，在这个数据结构中，面对不同的访问者，不同的类会有不同的反应，仅此而已。 


至此，小编的设计模式学习告一段落了，其实，就像人们常说的，面向对象设计模式的根本思想就是抽象，对类的抽象，对对对象的抽象，对方法的抽象。 

希望各位能抽出美好人生。