浅谈Java设计模式六大原则

单一职责原则

翻译过来可理解为一个类只负责一项原则

简单来说就是一个类只负责一个功能点或者模块，例如平时我们使用的UserController 以及 UserServices，它们仅负责和我们的User相关的业务。

里氏代换原则

翻译过来可理解为子类可以扩展父类的功能，但不可以改变父类原有的功能

在继承父类时，我们可以对父类原有的功能进行重写，但尽量不要覆盖父类原有的功能，子类的功能是一定比父类的功能多的。

依赖倒置原则

• 每个类尽量都有接口或者抽象类，或者抽象类和接口两都具备
• 变量的表面类型尽量是接口或者抽象类
• 任何类都不应该从具体类派生
• 尽量不要覆写基类的方法
• 如果基类是一个抽象类，而这个方法已经实现了，子类尽量不要覆写。类间依赖的是抽象，覆写了抽象方法，对依赖的稳定性会有一定的影响

注：结合里氏替换原则使用

接口隔离原则

翻译过来可理解为设计接口功能尽量细粒度，使接口为最小功能单元

• 客户端不应依赖它不需要的接口
• 类间的依赖关系应该建立在最小的接口上

迪米特法则(LOD)

翻译过来可理解为降低代码耦合性（局部变量中，不要引入新的类）

优点：

• 客户端不应依赖它不需要的接口
• 类间的依赖关系应该建立在最小的接口上

实通俗来理解就是，不要在一个接口里面放很多的方法，这样会显得这个类很臃肿。接口应该尽量细化，一个接口对应一个功能模块，同时接口里面的方法应该尽可能的少，使接口更加灵活轻便。或许有的人认为接口隔离原则和单一职责原则很像，但两个原则还是存在着明显的区别。单一职责原则是在业务逻辑上的划分，注重的是职责。接口隔离原则是基于接口设计考虑。

缺点：

• 在类的划分上，应该创建弱耦合的类。类与类之间的耦合越弱，就越有利于实现可复用的目标。
• 在类的结构设计上，尽量降低类成员的访问权限。
• 在类的设计上，优先考虑将一个类设置成不变类。
• 在对其他类的引用上，将引用其他对象的次数降到最低。
• 不暴露类的属性成员，而应该提供相应的访问器（set 和 get 方法）。
• 谨慎使用序列化（Serializable）功能。

开闭原则

翻译过来可理解为对扩展开放，对修改关闭，尽量不对原有的代码修改进行扩展

使用：

• 抽象约束
  抽象对一组事物的通用描述，没有具体的实现，也就表示它可以有非常多的可能性，可以跟随需求的变化而变化。因此，通过接口或抽象类可以约束一组可能变化的行为，并且能够实现对扩展开放。
• 元数据控件模块行为
• 制定项目章程
• 封装变化
  将相同的变化封装到一个接口或抽象类中，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同变化出现在同一个接口或抽象类中。