记录生活中的点点滴滴

0%

设计原则

这一篇主要写一下我们在编程过程中一些常见的设计原则,像SOLID原则、KISS原则、YAGNI原则、DRY原则、迪米特原则等,这些原则其实我们都会不经意的使用,这些思想感觉也挺有趣的,对于一个宏观的编程设计什么的感觉还是很有帮助的!

内聚和耦合

首先谈一谈内聚和耦合吧:

  • 内聚是从功能相关来谈,主张高内聚,把功能高度相关的内容不必要的分离开,就降低了内聚性
  • 耦合是从功能无关来谈,主张低耦合,把功能无关的内容随意结合起来,就增加了耦合性

OK,这两点只是写一下,只是讲清楚这两个概念,下面来看看SOLID原则,一共五个!

SOLID-SRP 单一职责原则

单一职责原则:一个类只负责完成一个职责或者功能,不要设计大而全的类,要设计粒度小、功能单一的类。

当然也不能无限小,还是符合高内聚的思想!

单一职责原则是为了实现代码高内聚、低耦合,提高代码的复用性、可读性、可维护性!

SOLID-OCP 对扩展开放,对修改关闭

如何理解“对扩展开发,对修改关闭”?

添加一个新的功能,应该是通过在已有代码的基础上扩展代码(新增模块、类、方法、属性等),而非修改已有代码的类、方法、属性等去完成,当然这并不绝对,并不是完全杜绝修改,而是以最小的修改代码的代价完成新功能的开发!

如何做到“对扩展开放,对修改关闭”?

要时刻有扩展意识、抽象意识、封装意识,多花时间去思考以后有哪些需求的更改等!

SOLID-LSP 里氏替换原则

子类对象能够替换程序中父类对象出现的任何地方,并且保证原来的程序的逻辑行为不变及正确性不被破坏。

理解里氏替换原则的核心,就是按照协议来设计。

即:父类定义了函数的约定(或者叫做协议),那子类可以改变函数内部的实现逻辑,但是不改变原有函数的约定!

这里的约定包括:函数声明要实现的功能;对输入输出、异常的约定;甚至一些特殊的情况等!

如何理解里氏替换原则和多态?

  1. 多态是面向对象的一大特性,他是一种代码实现的思路
  2. 而里氏替换是一种设计原则,用来指导继承关系中子类该如何设计,子类要保证在替换父类的时候,不改变程序的逻辑及不破坏原有程序的正确性。

SOLID-ISP 接口隔离原则

接口隔离原则:客户端不应该强迫依赖它不需要的接口

接口,可以分为下面3中情况,我们理解一下:

  • 一组接口集合:如果部分接口只被部分调用者使用,考虑将部分接口隔离出来,单独使用类
  • 单个API接口或函数:部分调用者只需要函数中的部分功能,考虑将函数拆分成粒度更小的多个函数
  • 若是OOP中的接口:接口的设计要尽量单一,不要让类和调用者,依赖不需要的接口函数

SOLID-DIP 依赖反转

主要要区分 控制反转,那个是创建对象的时候的思想!

依赖反转:高层模块不要依赖底层模块,高层模块和底层模块应该通过抽象来相互依赖,抽象不依赖于具体实现细节,具体实现细节依赖抽象

看似要求高层模块,其实是在规范底层模块的设计,低层次模块提供的接口要足够的抽象、通用,在设计的时候要考虑高层次模块的使用场景。

KISS原则

KISS我们可以理解成:Keep it Simple and Stupid

KISS原则是保持代码可读性和可维护的重要手段,简单并不是代码行数,还要考虑逻辑实现度、实现难度、代码可读性等!

YAGNI原则

You aren‘t gonna need it

不要过度设计

DRY原则

Don’t Repeat Yourself,不要重复自己

重复:

  • 实现逻辑重复
  • 功能语义重复
  • 代码执行重复

要去提高代码的复用度性,怎样提高?

  • 减少代码耦合
  • 满足单一职责原则
  • 模块化
  • 业务与非业务逻辑分离
  • 通用代码下沉
  • 封装、抽象、继承、多态
  • 利用模板等设计模式

迪米特原则

迪米特原则:每个模块只应该了解哪些与它关系密切的模块的有限知识,或者说每个模块之和自己的朋友说话,不要和陌生人说话

翻译一下:

不该有直接依赖关系的类之间,不要有依赖;有依赖关系的类之间,尽量只依赖必要的接口!

设计原则本身没有对错,只有能否用对之说,不要为了应用设计原则而去应用设计原则,我们在应用设计的时候,一定要具体问题具体分析!