S.O.L.I.D
S.O.L.I.D是面向对象设计和编程(OOD&OOP)中几个重要编码原则(ProgrammingPrinciple)的首字母缩写。
- SRP :The Single Responsibility Principle单一责任原则
- OCP :The Open Closed Principle 开放封闭原则
- LSP :The Loskop Substitution Principle里氏替换原则
- DIP :The Dependency Inversion Principle依赖倒置原则
- ISP :The Interface Segregation Principle接口分离原则
单一责任原则：
当需要修改某个类的时候原因有且只有一个（THERE SHOULD NEVER BE MORE THAN ONE REASONFOR A CLASS TOCHANGE）。换句话说就是让一个类只做一种类型责任，当这个类需要承当其他类型的责任的时候，就需要分解这个类。 比如：报表的内容和报表的格式都会变化改变，但是这两种变化的性质不同，一个是实质内在，一个是表面上的，SRP认为这是问题的两个方面，其实代表不同的职责，应该将它们分离放入不同的类或模块中，而不应该放在一起，否则的话，因为不同原因发生变化，导致对方变动，比如报表格式变新的样式，这个变化是不应该涉及到内容的。 反模式: 一个类处理的事情太多了, 应当进行分解
开放封闭原则
软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。这个原则是诸多面向对象编程原则中最抽象、最难理解的一个。 反模式: 一个模块的修改将导致其他模块的修改
里氏替换原则
当一个子类的实例应该能够替换任何其超类的实例时，它们之间才具有is-A关系 子类可以代替基类, 客户使用基类, 他们不需要知道派生类所做的事情. 反模式: if(a instanceof TypeA) {…} 这是一个针对行为职责可替代的原则，如果S是T的子类型，那么S对象就应该在不改变任何抽象属性情况下替换所有T对象。这里的抽象属性是指对象的字段属性。
我们使用接口时经常碰到一个问题，需要使用接口子类中的方法，而接口中没有这个方法，那么只能要么修改接口，要么将接口downcast为具体子类。为什么会出现这个尴尬现象？有几种情况导致，其中一种情况是是将当前的类重构到接口时，没有将类中所有方法extract到接口中，可能因为这些被你漏掉的方法不属于当前接口，那么，它又违背了单一职责原理，说明你当前这个类的方法设计得又不合理。
所以，如果单一职责设计的足够好，那么LSP原则则是检验的方法。LSP原则是对对象职责和协作的一种检验约束方法，此外还有DBC(designby contract)原则，为了保证实现接口的子类职责行为的约束，DBC三要素都必须被重视满足：
- Preconditions前置条件不能在子类中被强化。
- Postconditions后置条件不能在子类中被弱化。
- 子类自身不变性Invariants必须在子类自己中封装满足。这也是前面“不改变任何抽象属性”的意思。
依赖倒置原则
- 高层模块不应该依赖于低层模块，二者都应该依赖于抽象
- 抽象不应该依赖于细节，细节应该依赖于抽象
要针对接口编程，不针对实现编程。
接口分离原则
不能强迫用户去依赖那些他们不使用的接口。换句话说，使用多个专门的接口比使用单一的总接口总要好。 反模式：肥类(fat class), 有成堆的方法, 而且用户很少使用 SOLID原则如今在DCI架构中能够得到真正实现和发展。
包的设计原则：
- 发布/重用等价原则（REP）我们创建包的目的是为了给别人重用，所以重用的粒度就是发布的粒度。
- 公共闭合原则（CCP）因为相同原因而被修改的类应该放入一个包中，对应于“单一责任原则”。
- 公共重用原则（CRP）应该尽可能地将只被一个客户使用的包与被多个不同客户使用到的包分开。对应于“接口隔离原则”
- 非循环依赖原则（ADP）不要在包依赖图中出现循环依赖。如a依赖于b，b依赖于c，同时c又依赖于a。
- 稳定依赖原则（SDP）要依赖于稳定的包，而不要依赖于经常变化的包。对应于“依赖倒置原则”。
- 稳定抽象原则（SAP）稳定的包应当是抽象的。对应于“依赖倒置原则”。
设计模式 - DesignPattern
创建型
Abstract Factory（抽象工厂模式） ->(简单工厂模式)
Factory Method（工厂模式）
Builder（生成器模式）
Singleton（单件模式） ->(多例模式)
Prototype（原型模式）
结构型
Adapter（适配器模式）
Bridge（桥接模式）
Composite（组合模式）
Decorator（装饰模式）
Facade（外观模式，门面模式）
Flyweight（享元模式） ->(不变模式)
Proxy（代理模式）
行为型
Chain of Responsibility（职责链模式）
Command（命令模式）
Interpreter（解释器模式）
Iterator（迭代器模式）
Mediator（中介者模式）
Memento（备忘录模式）
Observer（观察者模式）
State（状态模式）
Strategy（策略模式）
TemplateMethod（模板方法模式）
Visitor（访问者模式）
