浅谈设计模式及如何选择设计模式
设计模式是面向对象技术的最新进展之一，它针对不断重复出现的问题，能够复用已有的、优秀的解决方案，因此提高了软件开发质量和代码重用性。
1 设计模式概念
设计模式是“对一些经过定制、能相互通信的对象和类的描述，用来解决特定场景下某个普遍的设计问题。”GOF经典设计模式使用类图、对象图、交互图等显示类与对象之间的关系和通信。其中类图用来描述各个类、类的结构以及它们之间的关系，对象图描述对象结构，而交互图描述的是对象间发生关系的流程。
设计模式种类众多，在GOF经典设计模式中，达23种之多，设计模式分类主要是根据目的准则和范围准则。目的准则说明模式是用来完成什么工作的，根据目的准则，模式可分为三种：（1）创建型：设计模式与对象创建无关，把对象的创建和其它部分的代码分离，从而创建对象会更加灵活。例如设计模式中的简单工厂模式，工厂方法模式，抽象工厂模式，创建者模式，原型模式，单例模式；（2）结构型：模式结构清晰，主要处理类或对象的组合，但是模式的每一部分的结构都专门负责完成某一职责。例如设计模式中的外观模式，适配器模式，代理模式，装饰模式，桥模式，组合模式，享元模式；（3）行为型：行为类模式主要描述类或对象之间的交互，以及类和对象的主要职责模板方法模式，观察者模式，状态模式，策略模式，职责链模式，命令模式，访问者模式，调停者模式，备忘录模式，迭代器模式，解释器模式。范围准则关注模式的制定主要用于类还是对象，其中“类模式”处理类与类之间的继承关系，这种关系是静态的，而“对象模式”处理对象之间的关系，这种关系是动态的。设计模式种类繁多，如何选出一个针对特定设计问题的模式是十分困难的。因此选择适合特定设计问题的设计模式，是人们比较关心的问题。
2 设计模式的选择
设计模式是面向对象的高层次解决方案，它不会过于关注具体问题的细节，所以应该把现实世界中存在的问题进行抽象，设计模式在选择对象和决定对象粒度方面都能起到作用。
⑴选择合适的对象。设计模式的对象来源于现实世界的抽象模型，针对具体问题描述，进行抽象，创建类和操作。但是在这些分析模型中得到的一些层次较高或较低的类，在现实世界里并不存在，比如数组等，设计模式能够确定这些在现实世界中找不到的类。
⑵决定对象粒度大小。设计模式能够决定对象的大小和数目，例如，外观模式能够使用对象表示完整的子系统，享元模式的对象粒度最小且数目众多，抽象工厂模式能够生产其它对象的对象。这些设计模式为对象粒度的选择提供了一定的依据。每一种设计模式都是为解决一类问题而出现的，例如：桥接（Bridge）模式属于结构性模式，其意图是分离抽象部分和实现部分，使这两部分相互独立，不会相互影响；解释器（Interpreter）模式属于行为模式，它的意图是给定一个语言及其语法语义，并定义一个解释器，用来使用这些语法语义表示这个语言的含义；生成器（Builder）模式属于创建型模式，它的意图是把复杂对象的构建和它的表示分开，使得同一个创建过程可以含有不同的表示。只有了解了设计模式的意图，才会比较容易地选择出，适合实际问题的一个或多个设计模式。
尽管设计模式在粒度和抽象层次上各不相同，但是它们之间还是具有一些关联，根据目的和使用范围不同，对设计模式进行了分类。分类能够指导应用设计模式的目的和范围，目的准则中的创建型模式与对象的创建有关，结构性模式关注于类或者对象的组合，行为性模式描述了类或者对象的交互关系和职责分配，范围准则是以类和对象来划分的，类模式是研究类与子类之间的静态关系，而对象模式关注的是对象之间的动态关系。如果确定了业务逻辑的目的和元素，就能缩小设计模式的选择范围，能够快速获得适合的设计模式或者模式组。
3 设计原则
⑴单一职责原则，即不能存在多于一个导致类变更的原因。简单的说就是一个类只负责一项职责。在软件设计中，秉承着“高内聚，低耦合”的思想，让一个类仅负责一项职责。http://www.youerw.com
⑵里氏替换原则，如果对每一个类型为T1的对象o1，都有类型为T2的对象o2，使得以T1定义的所有程序P在所有的对象o1都换成o2时，程序P的行为没有变化，那么类型T2是类型T1的子类型。包含4层含义：①子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。②子类可以实现父类的抽象方法，但是不能覆盖父类的非抽象方法。③当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。④当子类覆盖或实现父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
⑶依赖倒置原则，高层模块不应该依赖低层模块，两者都应该依赖其抽象，抽象不应该依赖细节，细节应该依赖抽象。
⑷接口隔离原则，接口中的方法应该尽量少，不要使接口过于臃肿，不要有很多不相关的逻辑方法。
总之，原则是前人经验的总结，在软件设计中具有一定的指导作用，但是不能完全照搬这些原则。对于接口隔离原则来说，接口尽量小，但是也要有限度。对接口进行细化可以提高程序设计灵活性是不争的事实，但是如果过小，则会造成接口数量过多，使设计复杂化，所以一定要适度。