[转]设计模式--六大原则与三种类型

一.6大原则

1.单一职责原则(Single Responsibility Principle)

定义:就一个类而言,应该仅有一个引起它变化的原因;

如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责变化可能会消弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受到意想不到的破坏;

T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障。也就是说职责P1和P2被耦合在了一起。

单一职责比较容易理解,但是在实际设计过程中容易发生职责扩散:因为某种原因,某一职责被分化为颗粒度更细的多个职责了。

解决办法:遵守单一职责原则,将不同的职责封装到不同的类或模块中。

2.里氏替换原则(LiskovSubstitution Principle)

定义:子类型必须能够替换掉它们的父类型;

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

只有子类可以替换父类,软件单位功能不受到影响时,父类才能真正被复用,而子类也能够在父类的基础上增加新的行为;里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,所以里氏代换原则是对实现抽象化的具体步骤的规范。

在进行设计的时候,我们尽量从抽象类继承,而不是从具体类继承。如果从继承等级树来看,所有叶子节点应当是具体类,而所有的树枝节点应当是抽象类或者接口。

3.依赖倒置原则(DependenceInversion Principle)

定义:

A.高层模块不应该依赖低层模块。两个都应该依赖抽象;

B.抽象不应该依赖细节,细节应该依赖抽象;(针对接口编程,而不是针对实现;)

面向过程的开发,上层调用下层,上层依赖于下层,当下层剧烈变动时上层也要跟着变动,这就会导致模块的复用性降低而且大大提高了开发的成本。依赖倒转很好的解决了这个问题;

4.合成/聚合原则(Composite/Aggregate Reuse Principle)

定义:尽量使用合成/聚合,尽量不要使用类继承;

优先使用对象的合成/聚合将有助于你保持每个类被封装,并被集中在单个任务上。这样类和类继承层次会保持较小规模,并且不太可能增长为不可控制的庞然大物;

为什么尽量不要使用类继承而使用合成/聚合?

对象的继承关系在编译时就定义好了,所以无法在运行时改变从父类继承的子类的实现

子类的实现和它的父类有非常紧密的依赖关系,以至于父类实现中的任何变化必然会导致子类发生变化

当你复用子类的时候,如果继承下来的实现不适合解决新的问题,则父类必须重写或者被其它更适合的类所替换

这种依赖关系限制了灵活性,并最终限制了复用性

5.迪米特法则(Law Of Demeter)

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

迪米特根本思想是:类之间的松耦合;

类之间的耦合越弱,越有利于复用,一个处于弱耦合的类被修改,不会对有关系的类造成波及。信息的隐藏促进了软件的复用;

广义的迪米特法则在类的设计上的体现:

优先考虑将一个类设置成不变类。

尽量降低一个类的访问权限。

谨慎使用Serializable。

尽量降低成员的访问权限。

6.开放-封闭原则(Open Closed Principle)

定义:软件实体(类,模块,函数等等)应该可以扩展,但是不可以修改;

对扩展开放,意味着有新的需求或变化时,可以对现有代码进行扩展,以适应新的情况。

对修改封闭,意味着类一旦设计完成,就可以独立完成其工作,而不要对类进行任何修改。

这样的设计,能够面对需求改变却可以保持相对稳定,从而使系统在第一个版本以后不断推出新的版本;面对需求,对程序的改动是通过增加新的代码进行的,而不是更改现有的代码;

开放封闭原则,是最为重要的设计原则,Liskov替换原则和合成/聚合复用原则为开放封闭原则的实现提供保证。

二.3种类型

设计模式分为那几类,它们是怎么区分的,每一种模式类型的特点,包含具体模式呢?

设计模式按照目的来分,可以分为创建型模式、结构型模式和行为型模式。

1.创建型

创建型模式用来处理对象的创建过程,主要包含以下5种设计模式:

工厂方法模式(Factory Method Pattern)

抽象工厂模式(Abstract Factory Pattern)

建造者模式(Builder Pattern)

原型模式(Prototype Pattern)

单例模式(Singleton Pattern)

2.结构型

结构型模式用来处理类或者对象的组合,主要包含以下7种设计模式:

适配器模式(Adapter Pattern)

桥接模式(Bridge Pattern)

组合模式(Composite Pattern)

装饰者模式(Decorator Pattern)

外观模式(Facade Pattern)

享元模式(Flyweight Pattern)

代理模式(Proxy Pattern)

3.行为型

行为型模式用来对类或对象怎样交互和怎样分配职责进行描述,主要包含以下11种设计模式:

责任链模式(Chain of Responsibility Pattern)

命令模式(Command Pattern)

解释器模式(Interpreter Pattern)

迭代器模式(Iterator Pattern)

中介者模式(Mediator Pattern)

备忘录模式(Memento Pattern)

观察者模式(Observer Pattern)

状态模式(State Pattern)

策略模式(Strategy Pattern)

模板方法模式(Template Method Pattern)

访问者模式(Visitor Pattern)

三.总结

设计原则是实现代码复用,增加可维护性。而设计模式就是实现了这些原则,达到了代码复用和增加可维护行的目的。设计模式的重点还是熟练理解理论知识的基础上能够做大灵活的应用,让设计出来的系统更加健壮,代码更加优化。前期刚学习的时候,做到能够套用,随着熟练程度的加深,达到无招胜有招,将各种模式融合的系统的实践中。

原文地址:https://www.cnblogs.com/phpdragon/p/8298111.html

时间: 2024-08-07 04:47:34

[转]设计模式--六大原则与三种类型的相关文章

设计模式之总结篇(设计模式六大原则以及设计模式三种类型)

经过这半年的学习,自己对设计模式这门课程也有了一定的认知.前面也发了关于23个设计模式的博客.现在对这些设计模式进行一个整体的总结. 首先,设计模式有六大原则: 原则一.单一职责原则 定义:There should never be more than one reason for a class to change(不要存在多于一个导致类变更的原因).通俗的说,即一个类只负责一项职责. 好处: 1.降低类的复杂度. 2.提高可读性. 3.提高可维护性. 4.变更引起的风险降低. 原则二.里氏替

设计模式的三种类型

设计模式(GOF模式)分为三种类型,共23类.一.创建型模式:单例模式.抽象工厂模式.建造者模式.工厂模式.原型模式.二.结构型模式:适配器模式.桥接模式.装饰模式.组合模式.外观模式.享元模式.代理模式.三.行为型模式:模版方法模式.命令模式.迭代器模式.观察者模式.中介者模式.备忘录模式.解释器模式.状态模式.策略模式.职责链模式.访问者模式.原文链接:https://blog.csdn.net/zhw0596/article/details/80852325 原文地址:https://ww

java设计模式六大原则

目录: 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置原则 设计模式六大原则(4):接口隔离原则 设计模式六大原则(5):迪米特法则 设计模式六大原则(6):开闭原则 设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案

设计模式六大原则-----转载

目录: 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置原则 设计模式六大原则(4):接口隔离原则 设计模式六大原则(5):迪米特法则 设计模式六大原则(6):开闭原则 设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案

设计模式六大原则【转】

设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使职责P1发生故障风险. 说到单一职责原则,很多人都会不屑一顾

设计模式六大原则之依赖倒置原则

一.概念: 依赖倒置原则英文缩写DIP(Dependence Inversion Principle)原始定义:High level modules should not depend upon low level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. 翻译过来就三层含义

转:设计模式六大原则

目录: 设计模式六大原则(1):单一职责原则 设计模式六大原则(2):里氏替换原则 设计模式六大原则(3):依赖倒置原则 设计模式六大原则(4):接口隔离原则 设计模式六大原则(5):迪米特法则 设计模式六大原则(6):开闭原则 设计模式六大原则(1):单一职责原则 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案

【转】设计模式六大原则

设计模式六大原则 单一职责原则(Single Responsibility Principle) 定义:不要存在多于一个导致类变更的原因.通俗的说,即一个类只负责一项职责. 问题由来:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障. 解决方案:遵循单一职责原则.分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险:同理,当修改T2时,也不会使

初探设计模式六大原则

前言 我想用贴近生活的语句描述一下自己对六种原则的理解.也就是不做专业性的阐述,而是描述一种自己学习后的理解和感受,因为能力一般而且水平有限,也许举的例子不尽妥当,还请谅解 原本我是想用JavaScript编写的,但是JavaScript到现在还没有提出接口的概念,而用TypeScript写又感觉普及度还不算特别高,所以还是决定用Java语言编写 目录 设计模式有六大原则 单一职责原则 里氏替换原则 依赖倒置原则 接口隔离原则 迪米特原则 开闭原则 首先要提的是:六大原则的灵魂是面向接口,以及如