设计模式（Design pattern）：是针对设计问题的通用解决方案。
使用设计模式：可以把它应用到特定的应用中，用于解决相似的问题。
使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。
真正理解什么是设计模式，就是要透彻理解OO的四大要素：封装、继承、多态和关联。其中核心是封装的概念。
常用设计模式的一些优缺点 1 简单工厂模式（Static Factory Method） 适用场景工厂类负责创建的对象比较少。
客户只知道传入工厂类的参数，对于如何创建对象（逻辑）不关心。
由于简单工厂很容易违反高内聚责任分配原则，因此一般只在很简单的情况下应用。
工厂类是整个模式的关键。包含了必要的逻辑判断，根据外界给定的信息，决定究竟应该创建哪个具体类的对象。
通过使用工厂类，外界可以从直接创建具体产品对象的尴尬局面摆脱出来，仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的。明确了各自的职责和权利，有利于整个软件体系结构的优化。
缺点 由于工厂类集中了所有实例的创建逻辑，违反了高内聚责任分配原则，将全部创建逻辑集中到了一个工厂类中，它所能创建的类只能是事先考虑到的，如果需要添加新的类，则就需要改变工厂类了。当系统中的具体产品类不断增多时候，可能会出现要求工厂类根据不同条件创建不同实例的需求。这种对条件的判断和对具体产品类型的判断交错在一起，很难避免模块功能的蔓延，对系统的维护和扩展非常不利。这些缺点在工厂方法模式中得到了一定的克服。 2 策略模式（Strategy） 适用场景 多个类有不同的表现形式，每种表现形式可以独立成单独的算法。需要再不同情况下使用不同的算法，以后算法可能还会增加。对用户隐藏算法逻辑。 优点 每个算法单独封装，减少了算法和算法调用者的耦合。合理使用继承有助于提取出算法中的公共部分。简化了单元测试。 缺点 策略模式只适用于客户端知道所有的算法或行为的情况。策略模式造成很多的策略类，每个具体策略类都会产生一个新类。不过可以使用享元模式来减少对象的数量。 3 装饰模式（Decorator） 适用场景 需要扩展一个类的功能，或给一个类添加附加职责。需要动态的给一个对象添加功能，这些功能可以再动态的撤销。需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变的不现实。当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。 优点 Decorator模式与继承关系的目的都是要扩展对象的功能，但是Decorator可以提供比继承更多的灵活性。通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。 缺点 这种比继承更加灵活机动的特性，也同时意味着更加多的复杂性。装饰模式会导致设计中出现许多小类，如果过度使用，会使程序变得很复杂。装饰模式是针对抽象组件（Component）类型编程。但是，如果你要针对具体组件编程时，就应该重新思考你的应用架构，以及装饰者是否合适。当然也可以改变Component接口，增加新的公开的行为，实现“半透明”的装饰者模式。在实际项目中要做出最佳选择。 4 代理模式（Proxy） 适用场景 远程代理，为一个对象在不同的地址空间提供局部代表，这样就可以隐藏一个对象存在于不同地址空间的事实。虚拟代理，是根据需要创建开销很大的对象。通过它来存放实例化需要很长时间的真是对象。安全代理，用来控制真实对象访问时的权限。智能指引，是指当调用真是的对象时，代理处理另外的一些事情。 优点 职责清晰，真实的角色就是实现实际的业务逻辑，不用关心其他非本职责的事务，通过后期的代理完成一件完成事务，附带的结果就是编程简洁清晰。代理对象可以在客户端和目标对象之间起到中介的作用，这样起到了中介的作用和保护了目标对象的作用。高扩展性 缺点 在客户端和目标对象增加一个代理对象，会造成请求处理速度变慢。增加了系统的复杂度。 5 工厂方法模式（Factory Method） 适用场景 工厂方法模式是new一个对象的替代品，所以在所有需要生成对象的地方都可以使用，但是需要慎重地考虑是否要增加一个工厂类进行管理，增加代码的复杂度。需要灵活的、可扩展的框架时，可以考虑采用工厂方法模式。工厂方法模式可以用在异构项目中，例如通过WebService与一个非Java的项目交互，虽然WebService号称是可以做到异构系统的同构化，但是在实际的开发中，还是会碰到很多问题，如类型问题、WSDL文件的支持问题，等等，从WSDL中产生的对象都认为是一个产品，然后由一个具体的工厂类进行管理，减少与外围系统的耦合。可以使用在测试驱动开发的框架下，例如，测试一个类A，就需要把与类A有关联关系的类B也同时产生出来，我们可以使用工厂方法模式把类B虚拟出来，避免类A与类B的耦合。目前由于JMock和EasyMock的诞生，该使用场景已经弱化了，读者可以在遇到此种情况时直接考虑使用JMock或EasyMock。 优点 良好的封装性，代码结构清晰，减少模块间的耦合。工厂方法模式的扩展性非常优秀。屏蔽产品类。工厂方法模式是典型的解耦框架。 缺点 使用者必须知道相应工厂的存在。每次增加一个产品时，都需要增加一个具体类和对象实现工厂，是的系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。 6 原型模式（Prototype） 适用场景 某些结构复杂的对象的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是他们却拥有比较稳定一致的接口。一般在初始化的信息不发生变化的情况下，克隆是最好的方法。 优点 隐藏了对象创建的细节。提高了性能。不用重新初始化，动态获得对象运行时的状态。 缺点 适用性不是很广。每一个类必须配备一个克隆方法。配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。 7 模板方法模式（Template Method） 适用场景 适用于子类中有重复的代码，可以把重复代码提取出来，放到父类中。 优点 提高代码复用性。帮助子类摆脱重复的不变行为。 缺点 考虑不全面统一出现问题。 好处重用性
扩展性
灵活性
结构型设计模式：松耦合
避免了客户端环境与产品对象复杂的构造逻辑耦合