前言
这篇文章是我写完三种设计模式之后才写的，究其原因呢，是由于今天get到了一些更为设计模式原则的东西，不管是设计模式还是大家平时写的代码，都会无意中用到何遵守的，我打算用自己的话来写一遍。
你不知道的设计模式原则
单一职责原则
不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。
能分工协作的尽量分好工，各自负责自己的一块，并且把它做好就好了，避免相互影响。
里氏代换原则
所有引用基类的地方必须能透明地使用其子类的对象，也就是说子类可以扩展父类的功能，但不能改变父类原有的功能
当要继承前人写的类的时候，尽量不重写和重载里面的方法，因为你根本不知道，哪里会被影响到。继承方法也尽量尊重原逻辑不轻易改变。
依赖倒置原则
高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。
父亲模块不和其子模块相互依赖，最好都依赖第三方（抽象的类）,可以避免高耦合的坑，万一产品改策略，也可以轻松通过横向扩展（再来一个继承抽象类的子类）来解决，继承的话遵循里氏代换原则
接口隔离原则
客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
如果是通过接口进行编程的，不要将一堆抽象的方法放在接口类中，这样会造成继承的类还要去实现根本不属于它的方法，即使是接口，也尽量按照总分的概念去勾划，共用的写在一个接口类中，个别定制的应单独写，子类选择性继承接口类就好。
迪米特法则
一个对象应该对其他对象保持最少的了解。
典型的知道了太多更容易死的道理，放在代码里就是，写一个模块的时候尽量能分就分，一个模块包含越多耦合越大，越容易出错，拆成各自独立模块，即使出问题也不会全盘崩。
开闭原则
一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。
当产品需求变化时，尽量通过扩展软件实体的行为来实现变化（加类，加方法），而不是通过修改已有的代码来实现变化。
一个问题的讨论
很多优化的地方都在说：高内聚低耦合，那么问题来了，高内聚低耦合真的好吗？
- 1
- 1
我的看法是：看业务的具体逻辑，因为高内聚低耦合的话，一旦某一块业务相互关联又比较复杂，会直接导致很多独立的代码块存在，即使有备注，看起代码会给人一种跳来跳去的感觉，阅读性会降低，直接导致维护性会降低，当代码接手给别人时候，后人将在理解代码方面花费很多时候，寸步难行。听说适当的耦合代码和按具体依赖关系分块更配哦～
单纯的按照前人总结的抽象的规范写代码也是不对的，好的设计模式是一步一步改出来的，而不是一开始就设计好的。