一个对象（方法）只做一件事情。
（1）代理模式
（2）迭代器模式
（3）单例模式
（4）装饰者模式
（1）如果随着需求的变化，有两个职责总是同时变化，那就不必分离他们。
（2）职责的变化轴线仅当它们确定会发生变化时才具有意义，即使两个职责已经被耦合在一起，但它们还没有发生改变的征兆，那么也许没有必要主动分离他们。
（1）优点：降低了单个类或者对象的负责度，按照职责把对象分解成更小的力度，这有助于代码的复用和单元测试。当一个职责需要变更时，不会影响到其他的职责。
（2）缺点：会增加编写代码的负责度。
一个软件实体应当尽可能少地与其他实体发生相互作用。
（1）中介者模式
（2）外观模式
软件实体（类、模块、函数）等应该是可以扩展的，但是不可修改
（1）发布-订阅模式
（2）模板方法模式
（3）策略模式
（4）代理模式
（5）职责链模式
让程序一开始就遵守开放-封闭原则，并不是一件很容易的事情，所以我们可以说服自己去接受不合理的代码带来的第一次愚弄。在最初编写代码的时候，先假设变化永远不会发生，这有利于我们迅速完成需求。当变化发生并且对接下来的工作造成影响的时候，可以在回过头来封装这些变化的地方，然后确保我们不会掉进同一个坑里。
接口是对象能响应的请求的集合
如果在函数中有一段代码可以被独立出来，那我们最好把这些代码放进另一个独立的函数中。这样做的好处主要有以下几点：
（1）避免出现超大函数
（2）独立出来的函数有助于代码复用
（3）独立出来的函数更容易被覆写
（4）独立出来的函数如果拥有一个良好的命名，它本身就起到了注释的作用
如果一个函数体内有一些条件分支语句，而这些分支语句内部散步了一些重复的代码，那么就有必要进行合并去重工作。