设计模式的六大原则 ---- 理论知识
1. 单一职责原则(SRP)(Single Responsibility Principle)
2. 里氏替换原则(LSP)(Liskov Substitution Principle)
3. 依赖倒置原则(DIP)(Dependence Inversion Principle)
4. 接口隔离原则(ISP)(Interface Segregation Principle)
5. 迪米特原则(LOD)(Law Of Demeter)
6. 开闭原则(OCP)(Open Closed Principle)
1:单一职责原则(一个类只做一件事)
应用场景:
类T负责两个不同的职责:P1职责,P2职责。当P1需求发生变法时而需要修改类T时,就有可能导致原本运行正常的P2发生故障。
遵循单一原则,把P1跟P2分成两个类,每个类只关注一件事情避免因为需求的修改而引发不必要的故障
什么情况下可以违背单一职责原则:
只要逻辑足够简单,就可以在方法级别上违背单一职责原则
如果一个类足够简单,方法够少,就可以在类级别上违背单一职责原则
杂话:各种级别(方法/类/接口/类库/项目/系统)
优点:
1 类逻辑变得简单
2 代码稳定,可扩展性高
缺点:
1 代码会变多
2:里氏替换原则(任何使用基类的地方,其子类都可以透明的使用(继承,多态))
如果子类不能拥有父类的全部属性和行为,断掉继承
如果子类要修改父类的行为,使用override/virtual
总结来说,里氏替换原则就是规范了继承的使用
3:依赖倒置原则(上层模块不直接依赖下层模块,二者应通过抽象依赖(抽象类/接口类))
依赖抽象(抽象类/接口类),而不是依赖细节(实现类)
相对于细节,依赖抽象更稳定
基于抽象的架构,更稳定
杂谈:经常听到的几个词
1 控制反转(IOC):把依赖交给第三方容器来完成 (目的)
2 依赖注入(DI):实现控制反转的一种手段 (行为)
4:接口隔离原则(客户端不应该依赖于它不需要的接口,一个类对另一个类的的依赖应该建立在最小的接口上)
不要使用大而全的接口,这样导致实现不需要的方法
也不能拆分的太细,这样会导致使用不便
关于接口隔离原则,具体情况还需要根据业务需求来定,没有一个同一标准,该拆该合,都得需要自己度量
5:迪米特法则(最少知道原则)(一个对象只于关系最密切的朋友进行通讯,高内聚,低耦合)
类于类之间,要避免不必要的依赖
学校,老师,班级,学生四个类
学校只与老师通讯,老师只跟班级通讯,不要学校在关联老师的同时,又关联班级,这样会增加依赖、
场景:老师类中有一个班级的集合,班级类中有一个学生的集合
错误做法:在老师类中写一个方法,遍历出所有班级,在遍历中,又根据班级遍历出所有学生(这种写法虽然很爽,但是增加了不必要的依赖)
正确做法:在老师类中写一个方法,在班级类中写一个方法,老师类中遍历出所有班级,在遍历中在根据班级调用班级类中自身的方法获取所有的学生(减少了不必要的依赖)
杂谈:类与类的关系
纵向关系:继承 实现
横向关系:依赖(方法内部) 关联 组合 聚合(后三个:方法返回/参数 属性)
6:开闭原则(开放扩展,关闭修改)
没有任何的指导意义,只能算是一个愿景,架构的最理想状态
其他五个原则,都是为了辅助开闭原则,从而达到真正的理想状态
总结
1:六大原则并不是指具体的技术或者应用,而是一个指导性的原则,如何遵循六大原则需要自己度量,相当于一个建议,并不一定必须遵守六大原则,根据业务需求,自己做取舍
2:真正的业务需求中,往往会出现遵循了这个原则,却违反了另一个原则,具体侧重哪个原则,还要根据业务需求来定,不要盲目的追求。
3:尽可能的遵循六大原则来写代码,使你的应用变得健壮,扩展性高,易维护。
出处:https://www.cnblogs.com/liuqiwang/p/8470691.html