目录
比如：电脑内存坏了就应该更换内存，不应该更换CPU
（内存负责内存、CPU负责CPU）
就一个类而言，应该仅有一个引起它变化的原因。
如果你能想到多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该考虑类的职责分离。
比如：电脑内存不够只要插槽足够就可以扩展，硬盘不够可以用移动硬盘
开放-封闭原则，是说软件实体（类、模块、函数等等）应该可以扩展，但是不可修改。
有两个特征：
对于扩展是开放的，对于更改是封闭的。
我们在做设计的时候，就应该思考，怎样的设计才能面对需求的改变却可以保持相对稳定，从而使得系统可以在第一个版本以后不断推出新的版本呢？
也就是说，设计软件要容易维护又不容易出问题的最好办法，就是多扩展，少修改。
“开放-封闭原则”的精神所在：
对程序的改动是通过增加新代码进行的，而不是更改现有的代码。
注意：
开发人员应该仅对程序中呈现频繁变化的那些部分做出抽象（并不是每一个部分都要刻意地进行抽象）
（也叫依赖倒转原则）
例如：无论主板、CPU、内存、硬盘都是在针对接口设计的，如果针对实现来设计，内存就要对应到具体的某个品牌的主板，就会出现换内存需要把主板也换了的尴尬。
原话解释是：抽象不应该依赖细节，细节应该依赖于抽象。
就是：要针对接口编程，不要对实现编程。高层模块不应该依赖低层模块。高层和低层两个都应该依赖抽象。
一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。
也就是说，在软件里面，把父类都替换成它的子类，程序行为没有变化。
里氏代换原则：子类型必须能够替换掉它们的父类型。
（也叫最少知识原则）
比如你第一天上班需要装电脑，你不必直接和IT部的人联系。只需要让人事打电话在IT部找一个IT给你装电脑就行。
迪米特法则:
如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。
如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。
根本思想是强调了类之间的松耦合。