Java设计模式原则

Java设计模式原则

学了一些设计模式，看完了一把构建用的模式，自己也用了一点儿，感觉到了很多好处。但这些模式都遵循一些模式，自己代码再进行修改明显更简单，扩展也更棒。老师上课也提及了一个里氏替换原则，自己查了一下还有几个设计原则。
这些设计原则只有用到了才能感到他们的意义，代码不可能是一成不变的，也不可能是不修改的。这些原则都是前代软件工程师发现的有意义的东西，我们按照这些原则写的代码能达到很好的复用性和可扩展性，可读性也会加强。

一.单一职责原则

一个类只要负责一个职责，不要在设计中使用一个带有很多功能的类。当一个类能做到很多事情，我们应该把他拆开。
很多人为了高聚合把很多无关的事情交给一个类做，这让以后程序的功能很难修改与扩展。
这个很容易理解，提高类的可读性，并且降低类的复杂度，降低变更的风险。

二.接口隔离原则

客户端不应该依赖不需要的接口，如果一个实现类只需要接口的部分功能请把接口分开。
这也是不给客户端提供不需要的方法，不增加冗余代码。

三.依赖倒置原则

高层不应该依赖底层的细节，而应该依赖接口或者其抽象。
抽象永远要比细节稳定得多，一个程序的抽象功能一般不会大改，而细节总是在优化的。
如果依赖的是抽象，我们可以很简单的按照我们自己的想法修改实现细节。
接口与抽象类负责制定ADT的规范的。
依赖倒置的核心就是面向接口编程，面向抽象编程

四.开闭原则

软件应对扩展开放，对修改关闭。
与上面联系程序用抽象构建，实现扩展细节。
我认为开闭必须建立在依赖倒置上，对抽象的功能可以进行扩展，而不允许修改，抽象应该是程序得骨架。

五迪米特原则

对象应该对其他对象保持最少的了解，对象不应该依赖其他对象实现细节。
也有的人认为一个优秀的类设计，不允许一个对象成为另一个对象方法中的局部变量。
这样子不对外泄露信息。

六里氏替换原则

对继承自同一个类的对象，最好有相同的行为，就是尽可能少的重写已有方法。
重写已有方法本身是对父类的破坏，越多重写的方法，代表子类与父类的关系越远离。如果我们本身只想调用子类的重写方法，我们为什么要把他继承一个父类而不是让他们平级呢？
继承现在在被大规模的滥用，继承应该是严格的is-a关系。现在很多应该用代理，用聚合都在继承。继承不应该是一种随便拿来的增加复用性的工具，希望慎用继承，多用聚合组合。