文章目录

  • 写在前面
  • 设计模式
    • 单一职责原则
    • 接口隔离原则
    • 依赖倒转原则
    • 里氏替换原则
    • 开闭原则
    • 迪米特法则
    • 合成复用原则
  • 小结

写在前面

概念性的东西全是文字或代码容易看不下去,我尽量图文并茂。
还有开源中国放过我吧,发一篇转一篇,求求做个人吧!

设计模式


软件设计模式(Design pattern),又称设计模式,是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性、程序的重用性。

打个比方就像盖大厦和小木屋,当功能简单,函数和代码少时,我们能较轻松的直接上手;但如果是像大厦那样,功能复杂,需求可能变化且代码量大时,我们就不能直接上手就来,需要像建筑图纸那样提前规划设计,那设计模式就像软件(程序)的建筑图纸。

设计模式的目的是为了让软件(程序)具有更好的:

  1. 代码重用性
    相同功能的代码,不用多次编写,降低冗余
  2. 可读性
    编程规范性, 便于其他程序员的阅读和理解
  3. 可扩展性
    当需要增加新的功能时,非常的方便,也称为可维护性
  4. 可靠性
    当我们增加新的功能后,对原来的功能没有影响
  5. 使程序呈现高内聚,低耦合的特性
    模块内部紧密,但模块间依赖小,一者出错不影响他者

单一职责原则

单一职责原则(Single responsibility principle),即一个类应该只负责一项职责。如类A负责两个不同职责:职责1,职责2。当职责1需求变更而改变A时,可能造成职责2执行错误,所以需要将类A的粒度分解为A1、A2。

单一职责原则注意事项和细节

  1. 降低类的复杂度,一个类只负责一项职责。
  2. 提高类的可读性,可维护性
  3. 降低变更引起的风险
  4. 通常情况下,我们应当遵守单一职责原则,只有逻辑足够简单,才可以在代码级违反单一职责原则;只有类中方法数量足够少,可以在方法级别保持单一职责原则

接口隔离原则

接口隔离原则(Interface Segregation Principle),即客户端不应该依赖它不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上

比如:类A通过接口 I I I依赖类B,类C通过接口 I I I依赖类D,如果接口 I I I对于类A和类C来说不是最小接口,那么类B和类D必须去实现他们不需要的方法。

按隔离原则应当这样处理:将接口 I I I拆分为独立的几个接口,将类分别与他们需要的接口建立依赖关系,也就是采用接口隔离原则。

依赖倒转原则

依赖倒转原则(Dependence Inversion Principle),依赖倒转(倒置)的中心思想是面向接口编程,所谓“倒转”是指抽象不应该依赖细节,而是细节应该依赖抽象。也就是高层模块不应该依赖低层模块,二者都应该依赖其抽象。因为相对于细节的多变性,抽象的东西要稳定的多。
比如有个Person类,可以接受Email、QQ和微信的消息。如果都为其提供一个专门的方法,就会让代码非常的冗余:

可以引入一个IReceiver接口,让Person类依赖该接口。这样QQ、微信和Email各自实现IReceiver里面的方法即可:

(插播反爬信息 )博主CSDN地址:https://blog.csdn.net/qq_45034708

里氏替换原则

里氏替换原则(Liskov Substitution Principle)要求所有引用基类的地方必须能透明地使用其子类的对象。也就是在继承关系中,子类尽量不要重写父类的方法。继承实际上让两个类耦合性增强了,特别是运行多态比较频繁的时,整个继承体系的复用性会比较差。
比如一种极端情况:一个类继承了另一个类,但却重写了所有方法,那么继承的意义何在?说好的复用呢?

解决方法是把原来的父类和子类都继承一个更通俗的基类,在适当的情况下,可以通过聚合,组合,依赖等来代替。

开闭原则

开闭原则(Open Closed Principle)一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方)。也就是当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化。用抽象构建框架,用实现扩展细节。
开闭原则是编程中最基础、最重要的设计原则。编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则。

举个违反开闭原则的例子:
矩形Retangle和圆形Circle继承了图形类Shape(提供方),画图类GraphicEditor(使用方)会调用相关属性。

但是如果再新增一个三角形,就要在使用方GraphicEditor新增对应方法,修改地方较多,违背开闭原则。

改进:把Shape做成抽象类并提供抽象方法draw,让子类去实现即可。当新增图形种类时,只需让新的图形类继承Shape,并实现draw方法即可。使用方的代码就不需要修改,满足开闭原则。

迪米特法则

迪米特法则(Demeter Principle)又叫最少知道原则,即一个类对自己依赖的类知道的越少越好,核心是降低类之间的耦合。也就是说,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部。对外除了提供的public 方法,不对外泄露任何信息。
避免与非直接朋友的耦合,只与直接的朋友通信,所谓的直接朋友是出现成员变量,方法参数,方法返回值中的类。而出现在局部变量中的类不是直接的朋友。也就是说,陌生的类最好不要以局部变量的形式出现在类的内部

比如有学院员工类和学校员工类,然后各有一个管理类有可以获取其所有员工,学校员工管理类有方法打印全部员工。

具体代码:

void printAllEmployee(CollegeManager sub) {//获取到学院员工List<CollegeEmployee> list1 = sub.getAllEmployee();System.out.println("---学院员工---");for (CollegeEmployee e : list1) {System.out.println(e.getId());}//获取到学校总部员工List<Employee> list2 = this.getAllEmployee();System.out.println("---学校员工---");for (Employee e : list2) {System.out.println(e.getId());}}

分析SchoolManager类,发现Employee和CollegeManager都是它的直接朋友(出现在参数和返回值中),但CollegeEmployee不是直接朋友,是以局部变量的形式,违背了迪米特原则。
你以前是不是就这样写的,细思极恐,当头一棒

改进:避免依赖CollegeEmployee,封装在CollegeManager中,对外提供public方法即可。

void printAllEmployee(CollegeManager sub) {sub.printEmployee();//获取到学校总部员工List<Employee> list2 = this.getAllEmployee();System.out.println("---学校员工---");for (Employee e : list2) {System.out.println(e.getId());}}

合成复用原则

合成复用原则(Composite Reuse Principle)就是是尽量使用合成/聚合的方式,而不是使用继承




如果对于类间关系(比如上面聚合组合),或不懂怎么画UML类图,可参考我的另一篇博客:一文掌握UML类图:PlantUML实操分享

小结

设计原则核心思想

  1. 针对接口编程,而不是针对实现编程 。
  2. 把应用中可能需要变化的代码和不需要变化的代码分开独立。
  3. 都是为了交互对象间解耦合而操心。

原创不易,请勿转载(本不富裕的访问量雪上加霜 )
博主首页:https://wzlodq.blog.csdn.net/
微信公众号:唔仄lo咚锵
如果文章对你有帮助,记得一键三连❤

设计模式-七大原则(图解一目了然)相关推荐

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

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

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

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

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

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

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

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

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

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

  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. device.cpp
  2. css中调整高度充满_CSS(十三).高度如何铺满全屏
  3. R语言入门学习笔记 - 对R软件的认识
  4. H5:100款html5微信小游戏最新最新源码
  5. 车机鸿蒙系统 车型,华为鸿蒙车机系统提前曝光!首发车型是它?
  6. 服务器芯片将填补中国空白,3年迭代4次技术,芯片黑马填补国产空白,韩企的垄断被打破...
  7. kali系统安装DVWA
  8. git用户名和密码保存文件_GitHub 本地保存用户名和密码方法
  9. (六)1609.4协议详解
  10. 代数数、超越数、代数函数、超越函数
  11. [转](42)驱动中使用全局变量
  12. iOS开发脚踏实地学习day01-02-加法计算器和图片移动缩放旋转
  13. OJ---腐烂的橘子
  14. Python实现投影法分割图像(一)
  15. html清除js设置的浮动,css 怎么清除浮动
  16. [AFCTF2018]可怜的RSA
  17. php中尊敬的某某某先生代码,auth.class.php
  18. 深度学习之目标检测学习笔记——1、基本概念
  19. centos7安装google浏览器,解决双击无法启动问题
  20. 通过TCP各个状态,可以排除和定位网络或系统故障

热门文章

  1. Java、JSP大阳电动车销售系统的设计与实现
  2. AutoCAD 2007官方.NET教程(一)(C#版)
  3. 响应式鲜花店预订网站织梦源码
  4. 关于生僻字乱码的问题
  5. TwinCAT3 与 SMC(EX600总线模块)通讯
  6. SEO优化|如何让网站关键词排名快速提高
  7. 【最短路算法】第二弹:一文弄懂Bellman-Ford(贝尔曼福特算法)
  8. Python报错TypeError: Descriptors cannot not be created directly
  9. 某年的第几个月或第几个周换算为具体的日期 -- vue
  10. 刷单会入刑了你知道吗?四招教你迅速识别刷单!