设计模式原则学习

学习了《大话设计模式》，由于是疫情在家，对每个设计原则和每个模式都可以慢慢细看，以下是对设计原则的一些感司，设计原则是必不可缺少的。如果单单去看这几个原则，一会就看完。原则只是原则，是要尽量保持，而不是必须保持的哦！所以不能一言而论，根据业务和情景懂得变通。

单一原则

应该有且仅有一个原因引起类的变更。这个原则在使用的过程中要做到适度，如果过度使用的话，可以将一个类中所有的方法都对应做成一个类。 其实在使用过程中说白了就是根据业务或某一方面将功能归类，同一功能的放在一起，声明一个接口。我们根据用户的属性和用的行为，划分为两个接口。根据以上例子单一原则的有点也是显而易见:类的复杂性降低，可维护性高。

里氏替换原则

只要父类出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用这可能根本就不需要知道是父类还是子类。但是，反过来就不行了。这个原则用到的其实就是类的继承，在一些情况下继承的优点不言而喻，不过在项目中不要随便使用继承。继承是可以用其他设计模式替换的，比如装饰模式等。

继承具有以下缺点：

• 继承是侵入性的。只要继承，就必须拥有父类的所有属性和方法。这个危害性还是挺大的！
• 降低了代码耦合性。子类必须拥有父类的属性和方法，让子类自由的世界中多了些约束
• 增加了耦合性。当父类的常量、变量和方法被修改时，需要考虑子类的修改，而且在缺乏规范的环境下，这种修改时毁灭性的。

如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中已经发生”畸形”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承

依赖倒置原则

高层模块不应该依赖底层模块，两者都应该依赖其抽象(接口或实现类)。一句大白话就是面向接口编程也就是APP开发过程中，只要有接口文档，我们就可以实现APP啦，不需要后台人员api的实现。也可以这么理解。

接口隔离原则

建立单一接口，不要建立臃肿庞大的接口。单一职责要求的是类和接口职责单一，注重的是职责，这是业务逻辑上的划分，而接口隔离原则要求接口的方法尽量少。例如一个接口的职责可能包含10个方法，这10个方法都放在一个接口中，并且提供给多个模块访问，各个模块按照规定的权限来访问，在系统外通过文档约束“不使用的方法不要访问”，按照单一职位原则是允许的，按照接口隔离原则是不允许的，因为它要求“尽量使用多个专门的接口”。就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建议一个庞大的臃肿的接口。 我们在使用组件化的过程中，由于模块间的调用，每个模块都对外声明一个公共接口，这时候其实就违背了接口隔离原则。比如我们可以按照同一层级调用声明一个接口，不同层级的调用声明一个接口。

迪米特法则

一个对象应该对其他对象有最少的了解

• 只和朋友交流 朋友:出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内的类不属于朋友类 比如我们在方法中使用了一个局部对象变量，这就违背了这个原则
• 是自己的就是自己的 如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

开闭原则

一个软件实体如类、模块和函数应该对外扩展开放，对修改关闭。即软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有的代码来实现变化。上边啰嗦一下设计模式的原则，其实我们在项目实践中也就是因为代码违背了其中的原则，然后进行改进，进而演化出设计模式。所以设计模式都是基于以上原则产生的。

场景使用

责任链模式责任链模式的重点是在“链”上，由一条链去处理相似的请求在链中决定谁来处理这个请求，并返回相应的结果。通过这个定义想到了一些应用的场景，像在以前工程中由于业务场景的复杂性，就存在大量的if…else判断。这样的逻辑导致业务交叉在一起，导致每个业务不清晰，扩展起来不是很方便，并且在系统S中会导致类臃肿。这个时候一定要引入责任链模式，调用方不用关心真正的业务处理，只要关心业务分类就行，真正的业务交给一个实体类来处理，相信学习之后就会恍然大悟。

志伟石潍