一、面向对象设计原则
1、依赖倒置原则（DIP）
- 高层模块（稳定）不应该依赖于低层模块（变化），二者都依赖于抽象（稳定）。
- 抽象（稳定）不应该依赖于实现细节（变化），实现细节应该依赖于抽象（稳定）。
2、开放封闭原则（OCP）
- 对扩展开放，对更改封闭。
- 类模块应该是可扩展的，但是不可修改。
3、单一职责原则（SRP）
- 一个类应该仅有一个引起它变化的原因。
- 变化的方向隐含着类的责任。
4、Liskov替换原则（LSP）
- 子类必须能够替换它们的基类（IS-A）。
- 继承表达类型抽象
5、接口隔离原则（ISP）
- 不应该强迫客户程序依赖它们不用的方法。
- 接口应接小而完备。
6、优先使用对象组合，而不是类继承
- 类继承通常为”白箱复用“，对象组合通常为”黑箱复用“。
- 继承在某种程度上破坏了封装性，子类父类耦合度高。
- 而对象组合则只要求被组合的对象具有良好定义的接口耦合度低。
7、封装变化点
- 使用封装来创建对象之间的分界层，让设计者可以在分界层的一侧进行修改，而不会对另一侧产生不良的影响，从而实现层次间的松耦合。
8、针对接口编程，而不是针对实现编程
- 不将变量类型声明为某个特定的具体类，而是声明为某个接口。
- 客户程序无需获知对象的具体类型，只需要知道对象所具有的接口。
- 减少系统中各部分的依赖关系，从而实现”高内聚、松耦合“的类型设计方案。
二、设计模式
1、”组件协作“模式
- 现代软件专业分工之后的第一个结果是”框架与应用程序的划分“，”组件协作“模式通过晚期绑定，来实现框架与应用程序之间的松耦合，是二者之间协作时常用的模式。
典型模式：
（1）Template Method 模板方法
- 定义一个操作中的算法的骨架（稳定），而将一些步骤延迟（变化）到子类中。Template
Method使得子类可以不改变（复用）一个算法的结构即可重定义（override得写）该算法的某些特定步骤。
（2）Strategy 策略模式
- 定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（扩展，子类化）。
（3）Observer 观察者模式
定义对象间的一种一对多（变化）的依赖关系，以便当一个对象（Subject）的状态发生改变时，所有依赖于它的对象都得到通知并自动更新。
2、“单一职责”模式
- 在软件组件的设计中，如果责任划分的不清晰，使用继承得到的结果往往是随着需求的变化，子类急剧膨胀，同时充斥着重复代码，这时候的关键是划清责任。
典型模式：
（1）Decorator 装饰模式
- 动态（组合）地给一个对象增加一些额外的职责。就增加功能而言，Decorator模式比生成子类（继承）更为灵活（消除重复代码&减少子类个数）。
（2）Bridge 桥模式
- 将抽象部分（业务功能）与实现部分（平台实现）分离，使它们都可以独立地变化。
3、“对象创建”模式
- 通过“对象创建”模式绕开new，来避免对象创建（new）过程中所导致的紧耦合（依赖具体类），从而支持对象创建的稳定。它是接口抽象之后的第一步工作。
典型模式：
（1）Factory Method 工厂方法
- 定义一个用于创建对象的接口，让子类决定实例化哪一个类。Factory Method使得一个类的实例化延迟（目的“解耦，手段：虚函数）到子类。
（2）Abstract Factory 抽象工厂
- 提供一个接口，让该接口负责创建一系列“相关或者依赖的对象”，无需指定它们具体的类。
（3）Prototype 原型模式
- 使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象。
（4）Builder
4、“对象性能”模式
- 面向对象很好地解决了“抽象”的问题，但是必不可免地要付出一定的代价。对于通常情况来讲，面向对象的成本大都可以忽略不计。但是某些情况，面向对象所带来的成本必须谨慎处理。
典型模式：
（1）Singleton 单件模式
- 保证一个类仅有一个实例，并提供一个该实例的全局访问点。
（2）Flyweight 享元模式
-
运用共享技术有效地支持大量细粒度的对象。
