设计模式的七大原则

设计模式概述

  • 就是某类问题的通用解决方案,代表了最佳实践
  • 设计模式的本质是提高软件的维护性、通用性和扩展性,并降低软件的复杂度
  • 设计模式分为了三类,共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)是编程中最基础也是最重要的设计原则
  • 一个软件实体,例如类,应该对扩展开放(接口提供方),对修改关闭(对接口调用方)
  • 当软件需要变化时,尽量通过扩展软件实体,而不是修改已有的代码来实现,当我们想给类增加新的功能的时候,尽量不修改代码,或者少修改代码
  • 设计模式的目的就是遵循开闭原则,开闭原则是核心

迪米特法则

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

合成复用原则

  • 尽量使用合成、聚合的方式,而不是使用继承

你可能感兴趣的:(设计模式,设计模式)