设计原则

发布时间:2021-10-05 00:36:14 阅读:(236)

    设计原则

    SOLID原则

    SOLID 是面向对象设计(OOD)的五大基本原则的首字母缩写组合,由俗称“鲍勃大叔”的Robert C.Martin在《敏捷软件开发:原则、模式与实践》一书中提出来。这些原则结合在一起能够指导程序员开发出易于维护和扩展的软件。这五大原则分别是:S—单一职责原则,O—开放封闭原则,L—里氏替换原则,I—接口隔离原则,D—依赖倒置原则

    单一职责原则

    核心思想

    一个类应该有且仅有一个原因引起它的变更

    一个类只负责一项功能或一类相似的功能。当然这个“一”并不是绝对的,应该理解为一个类只负责尽可能独立的一项功能,尽可能少的职责。就好比一个人的精力、时间都是有限的,如果什么事情都做,那么什么事情都做不好;所以应该集中精力做一件事,才能把事情做好

    优缺点:

    优点:

    • 功能单一,职责清晰
    • 增强可读性,方便维护
      缺点:
    • 拆分得太详细,类的数量会急剧增加
    • 职责得度量没有统一的标准,需要根据项目实现情况而定

    开放封闭原则

    核心思想

    软件实体(如类、模块、函数等)应该对拓展开放,对修改封闭

    在一个软件产品的生命周期内,不可避免会有一些业务和需求的变化,我们在设计代码的时候应该尽可能地考虑这些变化。在增加一个功能时,应当尽可能地不去改动已有的代码;当修改一个模块时不应该影响到其他模块。

    里氏替换原则

    核心思想

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

    只要父类能出现的地方子类就能出现(就可以用子类来替换它)。反之,子类能出现的地方父类不一定能出现(子类拥有父类的所有属性和行为,但子类拓展了更多的功能)。

    依赖倒置原则

    核心思想

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

    高层模块就是调用端,低层模块就是具体实现类。抽象就是指接口或抽象类,细节是指具体的实现类。也就是说,我们只依赖抽象编程。

    把具有相同特征或相似功能的类,抽象成接口或抽象类,让具体的实现类继承这个抽象类(或实现对应的接口)。抽象类(接口)负责定义统一的方法,实现类负责具体功能的实现。

    接口隔离原则

    核心思想

    客户端不应该依赖它不需要的接口。用多个细粒度的接口来替代由多个方法组成的复杂接口,每一个接口服务于一个子模块。

    建立单一接口,不要建立庞大臃肿的接口,尽量细化接口,接口中的方法尽量少。也就是说,我们要为不同类别的类建立专用的接口,而不要试图建立一个很庞大的接口供所有依赖它的类调用。

    接口尽量小,但是要有限度。当发现一个接口过于臃肿时,就要对这个接口进行适当的拆分。但是如果接口过小,则会造成接口数量过多,使设计复杂化。所以接口大小一定要适度。

    优点
    • 提高程序设计的灵活性
    • 提高内聚,减少对外交互
    • 为依赖接口的类定制服务

    是否一定要遵守这些设计原则

    软件的设计是一个循序渐进、逐步优化的过程

    • 单一职责原则告诉我们实现类要职责单一
    • 里氏替换原则告诉我们不要破坏继承体系
    • 依赖倒置原则告诉我们要面向接口编程
    • 接口隔离原则告诉我们在设计接口的时候要精简单一
    • 开放封闭原则告诉我们要对扩展开放,对修改封闭

    LoD原则

    一个类对自己依赖的类知道的越少越好,这个类只需要和直接的对象进行交互,而不用在乎这个对象的内部组成结构。

    KISS原则(Keep It Simple and Stupid)

    “简单”就是要让你的程序能简单、快速地被实现;“愚蠢”是说你的设计要简单到傻瓜都能理解,即简单就是美!

    为什么要简单呢?因为大多数技术团队,成员的技术水平都参差不齐。如果你的程序设计得太复杂,有些成员可能无法理解这种设计的真实意图,而且复杂的程序讲解起来也会增加沟通成本。为什么说愚蠢呢?对有同样需求的一个软件,每个人都有自己独特的思维逻辑和实现方式,因此你写的程序对于另一个人来说就是个陌生的项目。所以你的代码要愚蠢到不管是什么时候,不管是谁来接手这个项目,都能很容易地被看懂;否则,不要让他看到你的联系方式和地址,你懂的。

    DRY原则(Don’t Repeat Yourself)

    不要重复你的代码,即多次遇到同样的问题,应该抽象出一个共同的解决方法,不要重复开发同样的功能。也就是要尽可能地提高代码的复用率。

    要遵循DRY原则,实现的方式很多:

    • 函数级别的封装:把一些经常使用的、重复出现的功能封装成一个通用的函数。
    • 类级别的抽象:把具有相似功能或行为的类进行抽象,抽象出一个基类,并把这几个类都有的方法提到基类去实现
    • 泛型设计

    YAGNI原则(You Aren’t Gonna Need It)

    你没必要那么着急,不要给你的类实现过多的功能,直到你需要它的时候再去实现。

    这个原则简而言之为—只考虑和设计必需的功能,避免过度设计。只实现目前需要的功能,在以后需要更多功能时,可以再进行添加。如无必要,勿增加复杂性。

    软件开发首先是一场沟通博弈。它背后的指导思想就是尽可能快、尽可能简单地让软件运行起来(do the simplest thing that could possiblywork)。

    Rule Of Three原则

    Rule of three 称为“三次法则”,指的是当某个功能第三次出现时,再进行抽象化,即事不过三,三则重构。

    这个准则表达的意思是:第一次实现一个功能时,就尽管大胆去做;第二次做类似的功能设计时会产生反感,但是还得去做;第三次还要实现类似的功能做同样的事情时,就应该去审视是否有必要做这些重复劳动了,这个时候就应该重构你的代码了,即把重复或相似功能的代码进行抽象,封装成一个通用的模块或接口。

    理由:

    • 省事
    • 容易发现模式
    • 防止过度冗余

    CQS原则(Command-Query Separation)

    • 查询(Query):当一个方法返回一个值来回应一个问题的时候,它就具有查询的性质;
    • 命令(Command):当一个方法要改变对象的状态的时候,它就具有命令的性质。