面向对象的设计原则

版权声明：转载请注明出处 https://blog.csdn.net/nk1212582/article/details/81228075

单一职责原则

就一个类而言，应该仅有一个引起它变化的原因

如果一个类承担的职责过多，就会把这些职责耦合在一起，一个职责的变化可能削弱或者抑制这个类完成其他职责的能力

例子：将游戏的界面和控制逻辑相分离

软件设计真正要做的许多内容，就是发现并分离职责

当你能想到多余一个的动机去改变一个类，那么这个类就有多个职责

 

开放—封闭原则

软件实体（如类、函数、模块等）应该可以扩展，但是不可修改，即对于扩展是开放的，对于更改时关闭的

设计人员必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化

最初编写代码时，假设不会发生变化；当发生变化时，就构造抽象来隔离以后发生的同类变化

面对需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码

拒绝不成熟的抽象和抽象本身一样重要

 

里氏代换原则

子类型必须能够替换掉它们的父类型

一个软件实体如果使用的是一个父类的话，那么一定适用于其子类，而且它觉察不出父类对象和子类对象的区别。也就是说，在软件里面，把父类替换成它的子类，程序的行为没有变化

只有当子类可以替换掉父类，软件单位的功能不受到影响时，父类才能真正被复用，而子类也能够在父类的基础上增加新的行为

正是由于子类型的可替换性才使得使用父类类型的模块在无需修改的情况下就可以扩展

 

依赖倒转原则

高层模块不应该依赖底层模块，两个都应该依赖抽象；抽象不应该依赖细节，细节应该依赖抽象

针对接口编程，不要针对实现编程

 

迪米特法则

又称最少知识原则

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一方法的话，可以通过第三者转发这个调用。

强调：在类的结构设计上，每一个类都应当尽量降低成员的访问权限

根本思想是强调了类之间的松耦合