面向对象设计原则

• 单一职责原则 Single Responsibility Principle
  • 从软件变化的角度来看，就一个类而言，应该仅有一个让他发生变化的原因。
  • 正确抽象是实现SRP的关键
• 开闭原则 Open-Closed Principle
  • 软件实体（类、模块、函数等等）应该是可以扩展的，但是不可修改的
  • 开闭原则是面向对象设计的核心，抽象是OCP的核心
  • 总有一些功能不能通过扩展来实现需要修改源代码，不要over-consider OCP
• 里氏替换原则 Liskov Substitution Principle
  • 在任何父类出现的地方都可以用其子类替代。同一个继承体系中的对象应该有共同的行为特征。
  • 继承关系(IS-A)是基于对象的行为而非其概念，行为依赖于上下文和具体场景
  • LSP例子：java.util.Properties is a java.util.Hashtable
  • LSP是理论的而且严格的，有时候实际不能完全满足LSP是可以接受的
• 依赖注入原则 Dependence Inversion Principle
  • 高层模块不应该依赖于低层模决，二者都应该依赖于抽象。
  • 进一步的，抽象不应该依赖于细节，细节应该依赖于抽象。
  • 针对接口编程，不要对实现编程
• 接口分离原则 Interface Segregation Principle
  • 接口应该是原子的、高内聚扮演独立的角色或提供独立的角色。
  • ISP可以看做是SRP在接口中的描述。
• 迪米特法则 Law Of Demeter
  • 一个对象应当对其他对象尽可能少的了解，只和直接依赖的对象通信降低各个对象之间的耦合，提高系统的可维护性
• 组合/聚合复用原则 Composite/Aggregate Reuse Principle
  • 在一个新的对象里面使用一些已有的对象，使之成为新对象的一部分；新的对象通过向这些对象的委派达到复用已有功能的目的。
  • 组合是黑盒复用,包含对象的细节对于客户是不可见的。
  • 继承是白盒复用，强耦合，代码是静态的被复用。
  • 继承破坏了封装，父类的细节暴露给了子类。
  • 继承的实现是静态的，运行时候不能改变，缺乏灵活性。

设计模式

• Creational Patterns 创建型(与对象创建相关)
  • Factory Method 工厂方法 (类模式)
  • Abstract Factory 抽象工厂
  • Singleton 单例
  • Builder 创建
  • Prototype 原型
• Structural Patterns 结构型(处理类或对象的组合)
  • Adapter 适配器 (类或对象模式)
  • Decorator 装饰器
  • Composite 合成
  • Facade 外观
  • Flyweight 享元
  • Proxy 代理
  • Bridge 桥梁
• Behavioral Patterns 行为型(对类或对象怎样交互和怎么分配职责进行描述)
  • Interpreter 解释器 (类模式)
  • Template Method 模板方法 (类模式)
  • Chain of Responsibility 责任链
  • Command 命令
  • Iterator 迭代器
  • Mediator 调停者
  • Memento 备忘录
  • Observer 观察者
  • State 状态
  • Strategy 策略
  • Visitor 访问者模式

类模式处理类和子类之间的关系，这些关系通过继承建立，是静态的，在编译时刻便确定下来了。
对象模式处理对象之间的关系，这些关系在运行时刻是可以变化的，更具动态性。
从某种意义上来说，几乎所有模式都使用了继承，所以这里类模式只指那些集中处理类之间关系的 模式，而大部分模式都属于对象模式。

• 创建型类模式将对象的部分创建工作延迟到子类(工厂方法)，而创建型对象模式则将它延迟到另一个对象中。
• 结构型类模式使用继承机制来组合类(类适配器)，而结构型对象模式则描述了对象的组装方式。
• 行为模式使用继承描述算法和控制流(模板方法,解释器)，而行为对象模式则描述一组对象怎样协作完成单个对象所无法完成的任务。

有些模式经常绑定一起使用，如Composite常和Iterator或Visitor一起使用；有些模式是可替换的Prototype常用来替换Abstract Factory；有些模式尽管使用意图不同，但产生的设计结果是很相似的，如Composite和Decorator的结构图相似的。

可以根据模式的“相关模式”部分所描述的它们怎样互相引用来组织设计模式，来进一步理解各种设计模式。

设计模式解决设计问题

1. 寻找合适的对象
   • 设计模式帮你确定并不明显的抽象和描述这些抽象的对象。描述过程或算法的对象现实中并不存在，但它们却是设计的关键部分
   • Strategy模式描述了怎样实现可互换的算法族。
   • State模式将实体的每一个状态描述为一个对象。
2. 决定对象的粒度
   • Facade模式描述了怎样用对象表示完整的子系统，Flyweight模式描述了如何支持大量的最小粒度的对象。
   • 其他一些设计模式描述了将一个对象分解成许多小对象的特定方法。Abstract Factory和Builder产生那些专门负责生成其他对象的对象。
   • Visitor和Command生成的对象专门负责实现对其他对象或对象组的请求。
3. 指定对象的接口
   • 设计模式通过确定接口的主要组成成分及经接口发送的数据类型，来帮助你定义接口。设计模式也许还会告诉你接口中不应包括哪些东西。
   • 设计模式也指定了接口之间的关系。Decorator和Proxy模式要求Decorator和Proxy对象的接口与被修饰的对象和受委托的对象一致。
   • Visitor模式中，Visitor接口必须反映出Visitor能访问的对象的所有类。
4. 设计应支持变化。获得最大限度复用的关键在于对新需求和已有需求发生变化时的预见性，要求你的系统设计要能够相应地改进。一些导致重新设计的一般原因，以及解决这些问题的设计模式 如下：
   • 通过显式地指定一个类来创建对象。在创建对象时指定类名将使你受特定实现的约束而不是特定接口的约束。
     • 设计模式：Abstract Factory, Factory Method, Prototype
   • 对特殊操作的依赖。当你为请求指定一个特殊的操作时，完成该请求的方式就固定下来了。为避免把请求代码写死，你将可以在编译时刻或运行时刻很方便地改变响应请求的方法。
     • 设计模式：Chain of Responsibility, Command
   • 对硬件或软件平台的依赖。外部的操作系统接口和应用编程接口API在不同的软硬件平台上是不同的。
     • 设计模式：Abstract Factory, Bridge
   • 对对象表示或实现的依赖。知道对象怎样表示、保存、定位或实现的客户在对象发生变化时可能也需要变化。对客户隐藏这些信息能阻止连锁变化。
     • 设计模式：Abstract Factory, Bridge, Memento, Proxy
   • 算法依赖算法。在开发和复用时常常被扩展、优化和替代。依赖于某个特定算法的对象在算法发生变化时不得不变化。
     • 设计模式：Builder, Iterator, Strategy, Template Method, Visitor
   • 紧耦合。紧耦合的类很难独立地被复用，因为它们是互相依赖的。松散耦合提高了一个类本身被复用的可能性，并且系统更易于学习、移植、修改和扩展。设计模式使用抽象耦合和分层技术来提高系统的松散耦合性。
     • 设计模式：Abstract Factory, Command, Facade, Mediator, Observer, Chain of Responsibility
   • 通过生成子类来扩充功能。通常很难通过定义子类来定制对象。每一个新类都有固定的实现开销(初始化、终止处理等)。定义子类还需要对父类有深入的了解。一般的对象组合技术和具体的委托技术，是继承之外组合对象行为的另一种灵活方法。过多使用对象组合会使设计难于理解。许多设计模式产生的设计中，你可以定义一个子类，且将它的实例和已存在实例进行组合来引入定制的功能。
     • 设计模式：Bridge, Chain of Responsibility, Composite, Decorator, Observer, Strategy
   • 不能方便地对类进行修改。有时你不得不改变一个难以修改的类(可能没有源代码或者可能会改变其已存在子类)
     • 设计模式：Adapter, Decorator, Visitor

选择设计模式

• 考虑设计模式是怎样解决设计问题的
• 浏览模式的意图部分
• 研究模式怎样互相关联
• 研究目的相似的模式
• 检查重新设计的原因
• 考虑你的设计中哪些是可变的。考虑你想要什么变化却又不会引起重新设计。最主要的一点是封装变化的概念，这是许多设计模式的主题。下表列出了设计模式允许你独立变化的方面，你可以改变它们而又不会导致重新设计。

设计模式概述