1. 封装
2. 继承
   1. 泛化
   2. 组合
3. 多态
   1. 覆盖
   2. 重载
4. 设计模式六原则
   1. 自由主题
   2. Liskov替换
      1. 设计模式
         1. 原型
         2. 建造者
         3. 观察者
         4. 解释器
      2. 解决方案
         1. 当使用继承时，遵循里氏替换原则。类B继承类A时，除添加新的方法完成新增功能P2外，尽量不要重写父类A的方法，也尽量不要重载父类A的方法。
         2. 父类中凡是已经实现好的方法（相对于抽象方法而言），实际上是在设定一系列的规范和契约，虽然它不强制要求所有的子类必须遵从这些契约，但是如果子类对这些非抽象方法任意修改，就会对整个继承体系造成破坏。而里氏替换原则就是表达了这一层含义。
         3. 继承弊端：会给程序带来侵入性，程序的可移植性降低，增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。
      3. 定义
         1. 定义1：如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2，使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化，那么类型 T2 是类型 T1 的子类型。
         2. 定义2：所有引用基类的地方必须能透明地使用其子类的对象。
      4. 问题由来
         1. 有一功能P1，由类A完成。现需要将功能P1进行扩展，扩展后的功能为P，其中P由原有功能P1与新功能P2组成。新功能P由类A的子类B来完成，则子类B在完成新功能P2的同时，有可能会导致原有功能P1发生故障。
   3. 依赖倒转
      1. 问题由来
         1. 类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
         2. 传递依赖关系有三种方式，以上的例子中使用的方法是接口传递，另外还有两种传递方式：构造方法传递和setter方法传递，相信用过Spring框架的，对依赖的传递方式一定不会陌生。
      2. 解决方案
         1. 将类A修改为依赖接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生联系，则会大大降低修改类A的几率。
         2. 依赖倒置原则基于这样一个事实：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。
         3. 在java中，抽象指的是接口或者抽象类，细节就是具体的实现类，使用接口或者抽象类的目的是制定好规范和契约，而不去涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。
         4. 在实际编程中，我们一般需要做到如下3点：
            1. 低层模块尽量都要有抽象类或接口，或者两者都有。
            2. 变量的声明类型尽量是抽象类或接口。
            3. 使用继承时遵循里氏替换原则。
         5. 总之，依赖倒置原则就是要我们面向接口编程，理解了面向接口编程，也就理解了依赖倒置。
      3. 定义
         1. 高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
      4. 设计模式
         1. 桥接
         2. 装饰
         3. 访问
         4. 策略
   4. 接口隔离
      1. 设计模式
         1. 组合
         2. 模板方法
         3. 迭代器
      2. 定义
         1. 客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
      3. 问题由来
         1. 类A通过接口I依赖类B，类C通过接口I依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须去实现他们不需要的方法。
         2. 可以看到，如果接口过于臃肿，只要接口中出现的方法，不管对依赖于它的类有没有用处，实现类中都必须去实现这些方法，这显然不是好的设计。
      4. 解决方案
         1. 将臃肿的接口I拆分为独立的几个接口，类A和类C分别与他们需要的接口建立依赖关系。也就是采用接口隔离原则。
         2. 对臃肿复杂的接口I进行拆分
         3. 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
   5. 迪米特
      1. 设计模式
         1. 外观
         2. 代理
         3. 中介者
      2. 定义
         1. 一个对象应该对其他对象保持最少的了解。
         2. 只与直接的朋友通信
      3. 问题由来
         1. 类与类之间的关系越密切，耦合度越大，当一个类发生改变时，对另一个类的影响也越大。
      4. 解决方案
         1. 尽量降低类与类之间的耦合。
         2. 低耦合，高内聚
         3. 使各个模块之间的耦合尽量的低，才能提高代码的复用率
   6. 单一职责
      1. 设计模式
         1. 单例
         2. 享元
         3. 命令
         4. 职责
         5. 备忘录
      2. 定义
         1. 不要存在多于一个导致类变更的原因
      3. 问题由来
         1. 类T负责两个不同的职责：职责P1，职责P2。当由于职责P1需求发生改变而需要修改类T时，有可能会导致原本运行正常的职责P2功能发生故障。
      4. 解决方案
         1. 遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。
   7. 开放-封闭
      1. 设计模式
         1. 工厂方法
         2. 抽象工厂
         3. 适配器
         4. 状态
      2. 定义
         1. 一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
      3. 问题由来
         1. 在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会给旧代码中引入错误，也可能会使我们不得不对整个功能进行重构，并且需要原有代码经过重新测试。
      4. 解决方案
         1. 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。
      5. 核心
         1. 实现开闭原则的关键就是抽象化.
         2. 找到系统的可变因素,将它封装起来
   8. （合成-复用）
      1. 组合-聚合优先于继承
   9. 一个类只负责一项职责
   10. 核心思想就是面向接口编程
   11. 一个类对另一个类的依赖应该建立在最小的接口上
   12. 子类可以扩展父类的功能，但不能改变父类原有的功能