3_设计模式的一些原则

单一职责模原则

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

使用单一职责原则的原因：

一个类承担了太多了职责，所有职责耦合在一起，一个职责的变化坑呢会削弱或者影响类完成其他职责的能力。比如游戏的显示和游戏的底层逻辑应该分开两者的职责是不同的，不应该在一个类中

 

开放-封闭原则

• 软件的实体（类，模块，函数等）应该可以拓展但是不能被修改

两个特征

• open to extension

• closed to modification

设计人员必须对于他设计的模块应该对哪种变化封闭做出选择，猜测出最有可能发生变化的类，然后构造出抽象来隔离这些变化

比如我们写一个加法类

如图一，如果想要添加新的算法，那么就要修改加法类

但是在图二中，我们只需要添加新的运算来继承运算类，就可以不用修改现有算法。

 

依赖倒转原则

• 高层模块不应该依赖低层模块，两个应该都依赖抽象

• 抽象不应该依赖细节，细节应该依赖接口

简单来说就是应该针对接口编程，而不是针对实现编程

 

比如：

一个项目需要调用数据库，我们把数据库调用代码写成函数，每次调用就使用函数，但是如果客户需要用到不同的数据库，因为两者绑定才一起，修改函数可能造成整体的崩溃

 

里氏替换原则

子类型必须可以替换父类型

比如鸟会飞，那么企鹅就不能继承鸟，因为企鹅不会飞，不能代替父类型

子类可以在父类的基础上增加，但是不能没有父类的某些特性或者方法

 

就是因为里氏替换原则，我们可以通过接口/抽象类的方式将高层和低层分开，修改低层模块高层不会受到影响