【程序设计】设计模式与设计原则

设计模式与设计原则,基本符合规则与原则的关系:

 设计模式是一个个具体问题的解决方案,设计模式是程序设计方法的

 设计原则反映了这些设计模式的指导思想,设计原则是程序设计方法的


设计原则可衍生出的设计模式,任何一种针对特定业务场景中的解决方法,虽然找不到对应的设计模式与之匹配,但若符合设计原则,也可以认为是一种全新的设计模式。

 

设计原则:

单一职责原则:

 

 

 单一职责原则英文原名为Single Responsibility Principle,简称SRP原则。
 含义:应该有且仅有一个原因引起类的变更。
 例子:一个视频播放系统,一个客户端类有两个功能接口,即视频播放接口和音频播放接口。虽然这样的设计很常见,但却不满足单一职责原则的。原因是,如果对视频播放有变更需求或者对音频播放有修改需求,都会变更视频客户端的类结构。符合单一原则的设计是,将视频播放单元和音频播放单元各建一个类,播放客户端继承两个类,构成客户端。
 单一职责原则的最大难点在于职责的划分

 

 

 

 

 

里氏替换原则:

 

 

 里氏替换原则英文原名为Liskov Substitution Principle,简称LSP原则。
 面向对象设计的最为基本原则之一
 含义:任何基类可以出现的地方,子类一定可以出现。
 LSP是继承复用的基石,只有当子类可以替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,子类也能够在基类的基础上增加新的行为。
 举例:对于一个鸟类,可以衍生出麻雀、喜鹊、布谷等子类,这些子类都可继承鸟类的鸣叫、飞行、吃食等接口。而对于一个鸡类,虽然它在生物学上属于鸟类,但它不会飞,那么符合LSP设计原则的情况下,鸡就不应该是鸟的一个子类:在鸟类调用飞行接口的地方,鸡类并不能出现。如果鸡类要使用鸟类的接口,应该使用关联关系,而不是继承关系。

 

 

 

 

依赖倒置原则:

 依赖倒置原则英文原名为Dependence Inversion Principle,简称DIP原则。
 含义:高层模块不应该依赖于低层模块,两者都应该依赖其抽象,高层模块和低层模块都应该由各自的抽象模块派生而来,同时接口设计应该依赖于抽象,而非具体模块。
 抽象不应该依赖于细节,细节应该依赖于抽象。
 将每个不可细分的逻辑叫作原子逻辑,原子逻辑组装,形成低层模块,低层模块组装形成高层模块。
 例子:司机与汽车是依赖的关系,司机可以有实习司机类、老司机类等派生;汽车可以有轿车、SUV、卡车等派生类。如果司机中设计一个接口drive,汽车是其参数,符合DIP设计原则的参数,应该是在基类司机类中,将基类汽车类作为参数,而司机的派生类中,drive的参数同样应该为基类汽车类,而不应该是汽车类的任一个派生类。

 

 

 

接口隔离原则

 

 

 接口隔离原则英文原名为Interface Segregation Principle,简称ISP原则。
 含义:类间的依赖关系不应该建立一个大的接口,而应该建立其最小的接口,即客户端不应该依赖那些它不需要的接口。
 接口可以指一些属性和方法的集合
 接口可以指特定业务下的接口(如函数,URL调用等)。
 接口应该尽量小,同时仅留给客户端必要的接口弃用没有必要的接口
 举例:如果要根据具体的数据,生成饼图、直方图、表格,这个类该如何设计?如果将生成饼图、直方图、表格等“接口”(这里的接口就是“操作”的集合的概念),写在一个类中,是不符合接口隔离原则的。符合ISP原则的设计应该是设计三个类,每个类分别实现饼图、直方图、表格的绘制。
 接口隔离原则和单一职责原则一样,涉及到粒度的问题,解决粒度大小,同样依赖于具体的业务场景,需要读者根据实践去权衡。

 

 

 

 

 

迪米特法则(最少知识原则):

 

 

 迪米特法则(Law of Demeter)也叫最少知识原则,英文Least Knowledge Principle,简称LKP原则。
 含义:一个对象应该对其它对象有最少的了解。
 举例:一个公司有多个部门,每个部门有多个员工,如果公司CEO要下发通知给每个员工,是调用接口直接通知所有员工么?其实不然,CEO只需和它的“朋友”类部门Leader交流就好,部门Leader再下发通知信息即可。而CEO类不需要与员工进行“交流”。
 迪米特法则要求对象应该仅对自己的朋友类交流,而不应该对非朋友类交流。
 朋友类具有以下特征:
  1)当前对象本身(self);
  2)以参量形式传入到当前对象方法中的对象;
  3)当前对象的实例变量直接引用的对象;
  4)当前对象的实例变量如果是一个聚集,那么聚集中的元素也都是朋友;
  5)当前对象所创建的对象。

 

 

 

 

 

开闭原则(重要):

 

 

 开闭原则英文原名为Open Closed Principle,简称OCP原则。
 含义:一个软件实体,如类、模块、函数等,应该对扩展开放,对修改关闭
 开闭原则是非常基础的一个原则,也有人把开闭原则称为“原则的原则”。
 对扩展开放:意味着模块的行为是可以扩展的,当高层模块需求改变时,我们可以对低层模块进行扩展,使其具有满足高层模块的新功能;
 对修改关闭:高层模块和低层模块都应该由各自的抽象模块派生而来,同时接口设计应该依赖于抽象,而非具体模块。,即对低层模块行为进行扩展时,不必改动模块的源代码。
 最理想的情况是:业务变动时,仅修改业务代码,不修改依赖的模块(类、函数等)代码,通过扩展依赖的模块单元来实现业务变化。
 举例:假设一个原始基类水果类,苹果类是它的派生类,苹果中包含水果的各种属性,如形状、颜色等;另有两个类,农民类和花园类,最高层次(业务层次)为农民在花园种苹果。如果此时,农民决定不种苹果了,改种梨,符合OCP原则的设计应该为基于水果类构建一个新的类,即梨类(对扩展开放),而并不应该去修改苹果类,使它成为一个梨类(对修改关闭)。
 修改应仅在最高层,即业务层中进行。

 

 

 

 

 

设计原则的好处:

 

 

由于设计原则是设计模式的提炼,因而设计原则的好处与设计模式是一致的,即:代码易于理解;更适于团体合作;适应需求变化等。

 

 

 

 

1、创建类设计模式与设计原则

 

 

 工厂模式:工厂方法模式是一种解耦结构,工厂类只需要知道抽象产品类,符合最少知识原则(迪米特法则);同时符合依赖倒置原则和里氏替换原则;
 抽象工厂模式:抽象工厂模式具有工厂模式的优点,但同时,如果产品族要扩展,工厂类也要修改,违反了开闭原则;
 模板模式:优秀的扩展能力符合开闭原则。

 

 

 

 

2、结构类设计模式与设计原则

 

 

 代理模式:代理模式在业务逻辑中将对主体对象的操作进行封装,合适的应用会符合开闭原则和单一职责原则;事实上,几乎带有解耦作用的结构类设计模式都多少符合些开闭原则;
 门面模式:门面模式不符合开闭原则,有时不符合单一职责原则,如若不注意,也会触碰接口隔离原则;
 组合模式:符合开闭原则,但由于一般在拼接树时使用实现类,故不符合依赖倒置原则;
 桥梁模式:桥梁模式堪称依赖倒置原则的典范,同时也符合开闭原则。

 

 

 

 

3、行为类设计模式与设计原则

 策略模式:符合开闭原则,但高层模块调用时,不符合迪米特法则。行为类设计模式多少会符合些单一职责原则,典型的如观察者模式、中介者模式、访问者模式等;
 责任链模式:符合单一职责原则和迪米特法则;
 命令模式:符合开闭原则。

 

 

原文:https://yq.aliyun.com/articles/71197?spm=a2c4e.11153940.blogcont280715.31.175692aawkXRdB

你可能感兴趣的:(设计模式,设计原则,程序设计,Python,Language,Python开发实战)