设计模式的七大原则

设计模式概述

  • 就是某类问题的通用解决方案,代表了最佳实践
  • 设计模式的本质是提高软件的维护性、通用性和扩展性,并降低软件的复杂度
  • 设计模式分为了三类,共23种:
    • 创建型模式:单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式
    • 结构性模式:适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式
    • 行为型模式:模板方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式

使用设计模式的目的

  • 代码重用性:相同的代码,不用重复编写
  • 可读性:编码的规范性
  • 可扩展性:增加新功能时,非常方便
  • 可靠性:增加新的功能,对原有的功能没有影响
  • 高内聚、低耦合:模块内部很紧密,模块和模块间很松散

设计原则的核心思想

  • 找出应用中可能需要变化之处,把他们独立出来
  • 对针对接口编程。而不是针对实现编程
  • 为了交互对象之间的松散耦合设计而努力

设计模式的七大原则

  • 单一职责原则
  • 接口隔离原则
  • 依赖倒转原则
  • 里氏替换原则
  • 开闭原则(ocp)
  • 迪米特法则
  • 合成复用原则

单一职责原则

  • 对类来说,一个类应该只负责一项职责
  • 如果一个类负责两个职责:职责1和职责2,当职责1变化时有可能会引起职责2的变化,所以应该把这个类的粒度分为A1和A2
  • 优点:
    • 可以降低类的复杂度
    • 提高了类的可读性,可维护性
    • 降低了变更引起的风险
  • 通常情况下应该遵循单一职责原则,除非逻辑足够简单,才能在代码层面违反单一职责原则
  • 只有类中的方法足够少,可以在方法级别保持单一职责原则,如果方法很多,还是应该分成多个类

接口隔离原则

  • 客户端不应该依赖他不需要的接口,即一个类对另一个类的依赖应该建立在最小的接口上
  • 例如:
    • 接口类interface1有三个接口,实现类A只会用到其中两个接口,也必须实现剩下一个接口,出现这种情况,就说明interface1不是最小接口,存在不需要的接口,违反了接口隔离原则
    • 所以需要把interface1拆分为独立的接口,实现类只和他们需要的方法建立依赖关系

依赖倒转原则

  • 高层模块不应该依赖低层模块,二者都应该依赖其抽象
  • 抽象不应该依赖细节,细节应该依赖抽象
  • 依赖倒转的中心思想是面向接口编程
  • 相对于细节的多变性,抽象的东西要稳定的多,以抽象为基础搭建的架构比细节为基础的架构要稳定的多,在java中,抽象指的是接口或则抽象类,细节就是具体的实现类
  • 使用接口或者抽象类的目的是制定好规范,而不涉及任何具体的操作,把展示细节的任务交给他们的实现类去完成

里氏替换原则

  • 继承
    • 继承包含了这么一层含义:父类中凡是已经实现好的方法,实际上就是在设定规范,虽然不要求所有子类必须遵循这写规范,但是如果子类对这些已经实现的方法做任意修改,就会对整个继承体系造成破坏
    • 继承再给程序设计带来便利的同时,也带来了弊端,例如:
      • 使用继承会给程序带来侵入性,是程序的可移植性降低,增加了对象间的耦合关系
      • 如果一个类被其他类继承,对这个类的修改必须考虑其他子类,并且修改父类后,所有子类的功能都有可能出现问题
  • 里氏替换原则描述了如何正确的使用继承
    • 如果对每个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都替换成o2时,程序的行为没有发生变化,那么类型T2是类型T1的子类型
    • 也就是说:所有引用基类的地方必须能透明使用其子类的对象
    • 所以在使用继承时,遵循里氏替换原则,在子类中尽量不要重写父类中的方法
    • 继承会增加两个类的耦合,在适当的情况下,可以通过聚合、组合、依赖来解决问题,例如抽取更基础的父类

开闭原则(ocp)

  • 开闭原则(open closed principle)是编程中最基础也是最重要的设计原则
  • 一个软件实体,例如类,应该对扩展开放(接口提供方),对修改关闭(对接口调用方)
  • 当软件需要变化时,尽量通过扩展软件实体,而不是修改已有的代码来实现,当我们想给类增加新的功能的时候,尽量不修改代码,或者少修改代码
  • 设计模式的目的就是遵循开闭原则,开闭原则是核心

迪米特法则

  • 一个对象应该对其他对象保持最小的了解
  • 类与类关系越密切,耦合度越大
  • 迪米特法则的核心是降低类之间的耦合
  • 迪米特法则又叫最少知道原则,即一个类对自己依赖的类知道的越少越好,对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部
  • 迪米特法则还有个更简单的定义,只与直接的朋友通信,应该避免类中出现非直接朋友的耦合(对于被依赖的类不管多么复杂,都尽量将逻辑封装在类的内部),直接的朋友指的是:
    • 每个对象都会与其他对象有耦合关系,只要两个对象之间有耦合关系,就认为这两个类是朋友关系
    • 耦合的方式有很多,例如:依赖、关联、组合、聚合等
    • 出现成员变量、方法参数、方法返回值的类为直接朋友,出现在局部变量中的类不是直接朋友,陌生的类最好不要以局部变量的形式出现在类的内部

合成复用原则

  • 尽量使用合成、聚合的方式,而不是使用继承
相关推荐
李广坤1 小时前
状态模式(State Pattern)
设计模式
李广坤2 小时前
观察者模式(Observer Pattern)
设计模式
李广坤3 小时前
中介者模式(Mediator Pattern)
设计模式
李广坤3 小时前
迭代器模式(Iterator Pattern)
设计模式
李广坤4 小时前
解释器模式(Interpreter Pattern)
设计模式
阿无,7 小时前
java23种设计模式之前言
设计模式
Asort8 小时前
JavaScript设计模式(八):组合模式(Composite)——构建灵活可扩展的树形对象结构
前端·javascript·设计模式
数据智能老司机8 小时前
数据工程设计模式——数据基础
大数据·设计模式·架构
笨手笨脚の10 小时前
设计模式-代理模式
设计模式·代理模式·aop·动态代理·结构型设计模式
Overboom18 小时前
[C++] --- 常用设计模式
开发语言·c++·设计模式