设计模式-六大原则
对于设计模式的六大原则，这里打算用简单几句话来进行阐述。
单一职责原则
1 含义：简单来讲，就是类、接口和方法只负责一件事情，只有一个原因引起变化。一个接口一个职责，一个类一个职责。
2 好处：
-
类的复杂性降低
-
代码可读性提高
-
可维护性提高
-
变更引起的风险降低
3 难点：如何划分职责？因为职责和变化的原因是不可量化、不可度量的，所以那个接口或类负责哪个职责是很难划分。这些需要根据具体项目来划分，需要一定的工作经验。
4 如何使用：接口一定要做到单一职责。类的设计尽量做到只有一个原因引起变化。可以考虑可变因素、不可变因素和相关的收益成本比率。不一定能做到最优，但一定要向着极优设计。
里氏替换原则
1 含义：简单来说，就是父类可以出现，那么子类也可以出现。
2 如何使用：
- 子类必须完全实现父类的方法
- 子类可以有自己的个性，但不推荐，尽量避免子类有个性。
- 覆盖或实现父类的方法时，输入参数可以被放大。如果是覆盖，子类中方法的输入参数必须与父类中被覆写的方法的传入参数相同或者更宽松。否则，会造成子类在没有覆写父类的方法的前提下，子类的方法被执行，这样会造成业务逻辑混乱。
- 覆盖或实现父类的方法时，输出结果可以被缩小。
依赖倒置原则
1 含义：简单来说，就是面向接口编程。
2 好处：可扩展、易维护
3 缺点：
- 最难以实现的
- 现实生活中存在必须依赖细节的事物，要具体问题具体分析。
4 如何使用：
- 每个类尽量都有接口或者抽象类
- 变量的表面类型尽量使接口或者抽象类
- 不应该从具体类再派生出子类
- 尽量不覆写父类的方法
- 结合里氏替换原则使用，父类可以出现，那么子类也可以出现。
接口隔离原则
1 含义：接口尽可能细化，同时接口中的方法尽量少。
2 与单一职责原则的区别：单一职责原则要求类和接口的职责单一，注重的是职责，这是从业务逻辑上划分，而接口隔离原则要求接口的方法尽量少。举个例子，一个接口的职责可能包含10个方法，这10个方法放在一个接口中符合单一职责原则的，但是不符合接口隔离原则的，应该按照不同的模块再进行切分。
3 如何正确使用：根据经验和常识决定接口的粒度大小，接口粒度太小会造成接口数量巨大，接口粒度太大会降低灵活性。
迪米特法则
1 含义：一个类应该对自己需要耦合或调用的类知道得最少。也就是说，一个对象调用其他对象的public方法，至于public方法里面做了什么，一概不关心。
2 核心观念：类间解耦，低耦合。
3 实际应用：
- 当然，这样会产生大量的中转类或者跳转类，提高了系统复杂性，为维护带来了难度。
- 如果一个类跳转了两次以上才能访问到另一个类，就需要进行重构了。
开闭原则
1 含义：一个软件实体，如模块、类、和函数，应该对扩展开发，对修改关闭。
一个非常虚的原则，确实六大原则中最基础的原则，是其他5大原则的精神领袖。
2 如何将该口号应用到实际工作中：
（1）抽象约束。
- 接口和抽象类，不允许出现接口或抽象类中不存在的public方法；
- 参数类型、引用对象尽量使用接口或者抽象类，而不是实现类
- 接口和抽象类尽可能稳定，一旦确定不允许修改
（2）元数据控制模块行为。
元数据只用来描述环境和数据的数据，通俗来讲就是配置参数，该参数可以从文件获取，也可以从数据库获取。
（3）制定项目章程。对项目来说，约定优于配置。
（4）封装变化。一，将相同的变化封装到一个接口或者抽象类中；二，将不同的变化封装到不同的接口或者抽象类中。23种设计模式就是从各个不同的角度对变化进行封装。
