设计模式原则杂谈

（英文缩写很关键，看有些书的时候，描述原则一言不合就上缩写，看的就很费劲，稍微记一下每个原则的引文缩写,我写的是看法，适合懂一点设计的人看）

单一职责原则SRP(Single Responsibilities Principle)：

定义：一个类负责就仅仅只是一个职责，只干一件事情

我的见解:这个模原则看起来特别简单，但是真的是特别难，因为单一职责就意味这个类是很简单了，但是整个系统的复杂度没有变，这样就会造成会有大量的类出现在这个系统里面，单看每个类很简单，但是类之间的关系变的多了，一多就容易负责。但是如果不按照单一职责的话，每个类就会很容易因为需求的变化而变化。改旧代码真的是比写新代码要麻烦。所以我们对于设计的基本要求就是少改代码。我对于这个痛点的解决办法是，做设计的时候，将粒度变大。一个模式负责一个功能。然后慢慢细化。就跟树枝一样。如果发生需求变化要加职责，优先在这个类上面加函数解决。函数入口要尽量开放，抽象一点，当这个函数承载的功能太多以后，再加函数方法，就是灾难了，这个时候赶紧重构出用新的类来解决，在代码还没成为灾难之前就解决到这个苗头。

开闭原则OCP（Open Close Principle）：

定义：对扩展开放，对修改关闭，在程序进行修改的时候，不修改原有代码，增加新的类新的方法，就可以扩展了。
我的见解:这个原则是做设计最基础的原则，其实是做好设计的结果。其他的模式和原则都遵循了，这个也就自然而然的遵循了。

里氏替换原则LSP（Liskov Substitution Principle）：

定义：里氏代换原则中说，任何父类可以出现的地方，子类一定可以替换。LSP 是继承复用最基本的，只有当子类可以替换掉父类，且该功能模块不受到影响.传递参数的时候，一定要用父类的定义。在运行的时候再决定使用哪个子类实现。子类必须完整地实现父类的方法。模板方法是违背LSP原则的。但是它又是必须的。因为它定义了规范，模板方法，里面内部的组合顺序是固定的，怎么逻辑实现交给子类。它要支持所有子类的变化。可以说它最小程度上破坏LSP原则。为了达到更具有变化的扩展性。

依赖倒置DIP（Dependency Inversion Principle）：

定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。依赖倒置原则其实就是面向接口编程，原则就是当有变化的时候，高层代码不动，修改底层代码。抽象接口方法不动，有变化扩展实现类。这是设计原则最核心的一部分。设计模式里面函数的交互是接口的都是遵循DIP原则。

接口隔离原则ISP（Interface Segregation Principle）：

定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。就是客户端不需要的功能不要提供出来。它的初心其实和单一职责很像。按照业务需求，把大接口划分为适当的几个小接口提供。和微服务的目的是一样的。你客户端依赖的少，有改动的话，改动的就也少。就是功能接口粒度小，改动的影响就会很小。这点在代码重构，该需求的时候体会真的是特别大。但是粒度太小也不行，这样就和单一职责一样，会使得类之间的关系很复杂。

迪米特法则LKP（Least Knowledge Principle）

定义：最少知道原则，就是说类和自己交互的对象知道地越少越好，我就知道你提供的公有方法，其他的什么都不知道，知道地越多，耦合越大。一般都是不用出现方法调方法调方法这种情况。这其实就是类间的松耦合，适当加一些中介也可以，但是不要过度使用，这样中介类太多，就更复杂了。

好的设计一个是方便扩展，一个是结构清晰，写代码的时候需要防护考量着一部分，尤其是底层代码。