设计模式原则

开闭原则

概念:对拓展开放,对修改关闭

 

例如: Javascript代码我们可以在给对象类型拓展新功能,但是不能修改Js引擎的源码.如果每个人都能任意修改浏览器内核〃那么情况将会很糟糕。很多框架和插件我们都可以理解为是对浏览器的扩展而并没有改变浏览器内核。

 

设计要求:要求软件设计师有提前预见性,预留好扩展接口。典型案例Js的原型链给拓展带来极大方便

单一职责原则

概念:单职责原则:一个类只负责一个功能领域中的相应职责。一个类尽量只完成一个功能,很多任务分别分工给很多类做。

 

情景模拟

假设类C具有两个功能a,b

用了一段时间我们发现a功能不再满足需求需要修改,这个时候我们就要修改类c。但是修改C很有可能会导致本身良好运营的b出故障。

也就是说有潜在风险,对于大型项目哪怕很小风险也会浪费大量时间解决。

 

解决方案:

对以上问题功能a单独开发个类来处理,功能b单独用B类来处理。这样以后功能a不满足需求只需要修改类A,不会影响到类B

 

优点：降低类的复杂度、易維护、易扩展、可读性强

缺点：把握好粒度就没这个缺点(如果粒度过细,使类或接口的数目几何倍数增加,爆炸式增长也会给控制带来麻烦)

里氏替换原则

里氏替换原则中说，任何基类可以出现的地方，子类一定可以出现。 里氏替换原则是继承复用的基石，只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。

依赖倒转原则

概念:依赖倒转原则( Dependency Inversion Principle,DRP):

1、高层模块不应该依赖低层模块,两者都应该依赖其抽象

2、抽象不应该依赖于细节,细节应当依赖于抽象

3、也可以理解为常说的面向接口编程,而非面向具体实现编程。

 

底层模块：一个逻辑的实现都是由原子逻辑组成的，不可分割的原子逻辑就是底层模块。

高层模块：底层模块的再组装就是高层模块。

抽象：抽象就是指接口或抽象类。

细节：细节就是实现类，实现接口或继承抽象类而产生的类就是细节。

 

经典案例:PDO数据库连接

PDO数据访问抽象层,符合依赖倒置原则,应用程序算是高层,具体数据库驱动算是低层,PDO中间模块算是抽象。

有了PDo让我们的程序可以很容易的在多种数据库间切换,而基本不用修改程序代码。