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

目的:降低代码复杂度、系统解耦合、提高可读性

含义:对于一个类,只有一个引起该类变化的原因;该类的职责是唯一的,且这个职责是唯一引起其他类变化的原因。

解决:将不同的职责封装到不同的类或者模块中。 当有新的需求将现有的职责分为颗粒度更小的职责的时候,应该及时对现有代码进行重构。当系统逻辑足够简单,方法足够少,子类够少或后续关联够少时,也可以不必严格遵循你SRP原则,避免过度设计、颗粒化过于严重。

实例:电线类Wire为居民供电,电压为220v;但是新的需求增加,电线也输送高压电,电压为200kv,原有电线类可以增加方法实现扩充,这就违背了单一职责原则。可以提供基类,创建两个派生类,居民供电线、高压输电线。

2.里氏代换原则(Liskov Substitution Principle)

目的:避免系统继承体系被破坏

含义:所有引用基类的地方必须能透明地使用其子类的对象。

解决:子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法;子类中可以增加自己特有的方法;当子类覆盖或实现父类的方法时,方法的前置条件(即方法的形参)要比父类方法的输入参数更宽松;当子类的方法实现父类的抽象方法时,方法的后置条件(即方法的返回值)要比父类更严格。如果子类不能完整地实现父类的方法,或者父类的一些方法在子类中已经发生畸变,则建议断开继承关系,采用依赖,聚合,组合等关系代替继承。

实例:已经定义鸟类具有两个翅膀飞的方法;新加入鸵鸟,不会飞,如果覆盖父类的方法,在两个翅膀飞的方法中什么也不做,就违背里氏替换原则,导致所有鸟都不会飞。应该创建并列的两种鸟基类,会飞与不会飞的。前置条件更宽松、后置条件更严格,比如父类返回Map,子类返回HashMap;父类接受HashMap形参,子类接受Map。

3.依赖倒转原则(Dependence Inversion Principle)

目的:避免需求变化导致过多的维护工作

含义:高层模块不应该依赖低层模块,二者都应该依赖其抽象;抽象不应该依赖细节;细节应该依赖抽象。

解决:面向接口编程,使用接口或者抽象类制定好规范和契约,而不去涉及任何具体的操作,把展现细节的任务交给他们的实现类去完成。

实例:母亲类Mother有讲故事方法TellStory,依赖一个Book类输入,并使用了Book类的getContent方法以便讲故事。那么下次需要母亲讲报纸上的故事、手机上的故事时,原有接口无能为力。这时,抽象一个包含getContent方法的IReader基类,Book、Newspaper、Cellphone各自实现。母亲的TellStory方法接受一个IReader实例,并调用getContent方法即可。

4.接口隔离原则(Interface Segregation Principle)

目的:避免接口过于臃肿

含义:客户端不应该依赖它不需要的接口,一个类对另一个类的依赖应该建立在最小的接口上。

解决:适度细化接口,将臃肿的接口拆分为独立的几个接口。

实例:考试接口,包含考语数外、理化生、政史地等方法。学生类,实现考试接口,参加考试。文科生类、理科生类派生自学生类,实现考试接口时,就都需要实现一些自己不需要的方法(因为文科生不考理化生、理科生不考政史地)。这时,需要对考试接口进行细化,分为基础科考试接口、文科考试接口和理科考试接口;学生类实现基础科考试接口;文科生、理科生另外各自实现文科考试接口、理科考试接口。

5.迪米特法则(Demeter Principle)

目的:降低类与类之间的耦合

含义:每一个软件单位对其他的单位都只有最少的知识,而且局限于那些与本单位密切相关的软件单位。

解决:不发生依赖、关联、组合、聚合等耦合关系的陌生类不要作为局部变量的形式出现在类的内部。

实例:校长管理老师,老师管理学生。校长需要全体点名时,首先对老师点名,但是不必通过老师获取学生的信息并点名,而应该让老师对各自管理学生的点名,否则校长和学生之间就发生了原本不必要的耦合,这样当学生类发生变化时,既要修改老师类,也要修改校长类。

6.合成复用原则(Composite Reuse Principle)

目的:防止类的体系庞大

含义:当要扩展类的功能时,优先考虑使用合成/聚合,而不是继承。

解决:当类与类之间的关系是"Is-A"时,用继承;当类与类之间的关系是"Has-A"时,用组合。

实例:如桥接模式,抽象和实现可以独立的变化,扩展功能时,增加实现类即可;比如装饰模式,只需要一个类,即可为一类类扩展新功能。对于显示图形需求,用图形Shape类,和显示Paint类实现。每个Shape类有一个Paint类指针负责图形绘制显示。Paint类派生RedPaint类和BluePaint类,传递给Shape类,实现图形不同颜色绘制,这样图形绘制逻辑和图形绘制实现可独立变化。某天增加需求,所有的绘制需要加边框,可增加PaintDecorator类,派生自Paint基类,每一个PaintDecorator类有一个Paint对象指针,增加虚函数AddedPaint,重写Paint的绘制方法,增加AddedPaint方法的调用。增加BorderPaintDecorator类,派生自PaintDecorator类,重写AddedPaint方法,增加添加绘制边框代码。这样新增加一个类可以对原始所有画笔类的功能进行扩充。

7.开闭原则(Open Close Principle)

目的:提高扩展性、便于维护

含义:对扩展开放,对修改封闭。即系统进行扩展是被鼓励的,对现有系统代码进行修改是不被支持的。也就是说,当软件有新的需求变化的时候,只需要通过对软件框架进行扩展来适应新的需求,而不是对框架内部的代码进行修改。

解决:设计模式前面6大原则以及23种设计模式遵循的好,开闭原则自然遵守的好。对需求的变更保持前瞻性和预见性,就可以使抽象具有更广泛适用性,设计出的软件架构就能相对稳定。软件需求中易变的细节,通过从抽象派生出实现类来扩展。

附:合成复用原则的实例代码,组合使用桥接模式和装饰模式

#include <iostream>//绘制类
class Paint
{
public:virtual void Draw() = 0;
};//红色绘制类
class RedPaint : public Paint
{
public:void Draw(){std::cout << "Color Red!" << std::endl;}
};//蓝色绘制类
class BluePaint : public Paint
{
public:void Draw(){std::cout << "Color Blue!" << std::endl;}
};//图形类,使用桥接模式,将图形绘制逻辑与绘制实现解耦
class Shape
{
public:Shape(Paint* pt) : m_pPt(pt){     }virtual void Show(){std::cout << "Shape Style:" << std::endl;m_pPt->Draw();}protected:Paint* m_pPt;
};//长方形类
class Rectangle : public Shape
{
public:Rectangle(Paint* pt) : Shape(pt){}
};//圆形类
class Circle : public Shape
{
public:Circle(Paint* pt) : Shape(pt){}
};//附加绘制类,使用装饰模式,对原有绘制类进行功能扩展
class PaintDecorator : public Paint
{
public:PaintDecorator(Paint* pt) : m_pPt(pt) { }void Draw(){m_pPt->Draw();AddedPaint();}virtual void AddedPaint() = 0;protected:Paint* m_pPt;
};//附加边框类,对绘制类添加边框绘制功能
class BorderDecorator : public PaintDecorator
{
public:BorderDecorator(Paint* pt) : PaintDecorator(pt){}void AddedPaint(){std::cout << "With Border!" << std::endl;}
};void main()
{Shape* pShape = new Circle(new BorderDecorator(new RedPaint()));pShape->Show();return;
}

设计模式七大原则总结相关推荐

  1. Java面试之设计模式七大原则

    最近项目不太忙,不怎么加班,正利用晚上时间好好学习学习设计模式,之前可能多多少少都用到过,但是有些还是很模糊,这下正好系统的学一下. 好了,话不多说,进入正题. 1.什么是设计模式? 软件工程中,设计 ...

  2. 第 2 章 设计模式七大原则

    第 2 章 设计模式七大原则 1.设计模式的目的 编写软件过程中,程序员面临着来自 耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性 等多方面的挑战, 设计模式是为了让程序(软件),具有如下更好的 ...

  3. 设计模式——七大原则(附代码示例)

    一. 设计模式概念         对接口编程而不是对实现编程:优先使用对象组合而不是继承 二. 设计模式总览 1. 创建型模式(Creational Patterns):(5) 单例(Singlet ...

  4. 设计模式——七大原则

    设计模式--七大原则 汇总篇 1.单一职责 2.接口隔离 3.依赖倒转 4.里氏代换原则 5.开闭原则 6.迪米特法则 7.合成复用 汇总篇 1.单一职责 对类来说的,即一个类应该只负责一项职责.如类 ...

  5. 图解设计模式-设计模式七大原则

    Java设计模式 设计模式七大原则 设计模式的目的 编写软件过程中,程序员面临来自 耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性等多方面的挑战,设计模式是为了让 **程序(软件)**具有更好的 ...

  6. Day305.设计模式七大原则 -Java设计模式

    七大设计原则 一.设计模式的目的 编写软件过程中,程序员面临着来自 耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性 等多方面的挑战,设计模式是为了让程序(软件),具有更好的↓↓↓ 1. 代码重用 ...

  7. Java设计模式七大原则-单一职责原则

    目录 概述:设计模式的目的 设计模式七大原则 单一职责原则 单一职责原则注意事项和细节 概述:设计模式的目的 编写软件过程中,程序员面临着来自 耦合性,内聚性以及可维护性,可扩展性,重用性,灵活性 等 ...

  8. 设计模式七大原则介绍

    文章目录 1. 设计模式有哪些种类 2. 设计模式的目的 3. 设计模式七大原则 3.1. 单一职责原则 1. 基本介绍 2. 模拟场景 2. 接口隔离原则 1. 基本介绍 2. 模拟场景 3. 依赖 ...

  9. 设计模式七大原则知识概括

    设计模式七大原则知识概括 设计模式的目的 设计模式七大原则 单一职责原则 接口隔离原则 依赖倒转(倒置)原则 里氏替换原则 开闭原则 迪米特法则 合成复用原则 设计原则核心思想 设计模式的目的 目的: ...

  10. JAVA设计模式七大原则

    设计模式七大原则 设计模式目的 1.代码重用性 2.可读性 3.可读性 4.扩展性 5.可靠性 6.高内聚低耦合 七大原则 1.单一职责原则 一个类或方法中只做一件事情 2.接口隔离原则 一个类通过接 ...

最新文章

  1. 彻底搞透视觉三维重建:原理剖析、代码讲解、及优化改进
  2. 深度学习模型的中毒攻击与防御综述
  3. mysql动态sql循环语句_mysql存储过程循环遍历sql结果集,并执行动态sql
  4. 出参传递数组指针_C语言指针重难点详解
  5. CoreAnimation (CALayer 动画)
  6. Python input 函数 -Python零基础入门教程
  7. 终端传感了解吗?18个知识点为你扫盲
  8. java各种排序实现
  9. ListCtrl使用
  10. (最通俗易懂的)目标跟踪MOSSE、KCF
  11. CF 1260 D 题解
  12. WPS上配置使用Endnote软件
  13. DNS大全(114DNS 、阿里DNS、百度DNS 、360 DNS、Google DNS)
  14. 新一代医院信息系统(NGHIS)设计(2)——基础集成平台(I)
  15. idea中摸鱼插件_上班防摸鱼插件(知乎页面)
  16. 一名学生A希望访问网站www.google.com。学生A在其浏览器中输入http://www.google.com并按回车.....
  17. IIS 7.5 请求的内容似乎是脚本,因而将无法由静态文件处理程序来处理。
  18. 与非营利朕亨基金会合作 Keybase将保密通讯软体结合加密货币
  19. Java Android、IOS、前端、数据库、C++、Unity3D、Python学习资料
  20. 全球当下最厉害的 14 位程序员!最后一位好年轻啊

热门文章

  1. 串口控制器,电平脉冲触发,顺序轮换,间歇轮换,电磁阀继电器流水,8路,16路,32路
  2. java EE /servlet2/基础
  3. 【杂】国内游戏创作大赛汇总(望补充)
  4. 阿ken的HTML、CSS的学习笔记_CSS3选择器(笔记四)
  5. i7 13700k核显性能 酷睿i713700k参数 i7 13700k功耗
  6. 解析BMP GIF JPEG TGA PNG图像格式
  7. esp-01s接入天猫精灵与relay继电器控制电灯
  8. avoid mutating a prop directly since the value will be overwritten whenever完美解决
  9. DQN相关知识总结及演员-评论员算法介绍(DataWhale组队学习笔记)
  10. git pack文件过大