最新消息:www.yxkong.com也可以访问

常见设计原则

设计模式 yxkong 48浏览

设计模式是软件设计中常见问题的典型解决方案。它们就像能根据需求进行调整的预制蓝图, 可用于解决代码中反复出现的设计问题。

  • 设计模式相对比较软性,是对解决某类场景问题的高层描述;

  • 根据使用人的不同应用的也不同

  • 只是一种思想,没有好坏之分,只有更适合;

  • 我们应该关注要达到什么样的目的,怎么更加灵活的做到;

  • 软件中唯一不变的是变化,设计模式让我们想各种方法屏蔽这种变化;

设计模式包含:

  • 意图:简单描述问题和解决方案

  • 动机:进一步解释问题并说明模式会如何提供解决方案;

  • 结构:如何将软件结构组装起来并形成关系

设计原则:

SOLID原则 solid->稳定的

  • S Single Responsibility Principle: 单一职责原则

  • O open closed Principle: 开闭原则

  • L Liskov Substritution Principle: 里氏替换原则

  • I Interface Segegation Principle: 接口隔离原则

  • D Dependence inversion Principle: 依赖倒置原则

内聚:从功能相关来谈,主张高内聚,把功能高度相似的代码内聚到一起,方便统一维护;耦合:从功能无关来谈,主张低耦合。不要把明显无关的功能随意结合,以降低耦合性;在代码中,类与类之间的依赖关系简单清晰。即使两个类有依赖关系,一个类的代码改动也不会或很少导致依赖类的代码改动;

单一职责原则 SRP(Single Responsibility Principle)

定义:一个类或者模块只负责完成一个功能。特点:

  • 模块可以看作是类的抽象或者是聚合;

  • 单一,只是在特定的场景下单一, 比如一个类单一,一个模块单一

  • 单一尽可能设计的粒度小、功能单一

  • 比如下单功能,可能涉及到下单,查询用户,查询地址,优惠券使用,每一点都是单一功能,不要一写写一坨;

实现目的:从自身角度考虑代码的高内聚、低耦合、提高代码的复用性、可读性、可维护性;

开闭原则 OCP (Open Closed Principle)

定义:对扩展开放,对修改关闭

特点:

  • 添加新功能,在已有的代码基础上扩展代码(新增类、方法等),而非修改已有的代码

  • 开闭原则并不是完全杜绝修改,而是以最小的修改代码的代价来完成新功能的开发;

  • 同样的代码改动,在粗代码力度下,可以被被认定为修改,在细代码力度下,被认为是扩展;

  • 提高代码扩展性的方法:多态、依赖注入、面向接口编程、适配、装饰、策略、模板、责任链、状态等

  • 对扩展开放是未了应对软件的变化,对修改关闭是未了保证系统的稳定性,最后是未了让系统具备可扩展性(弹性);

  • 也不要一味的遵循开闭,导致代码的复杂度过度的增加;

  • 开闭也减少了测试的复杂度;

实现目的:基于自身考虑代码的结构,解决代码的扩展性的问题

里氏替换原则 LSP Liskov Substitution Principle

定义:值对象能够替换程序中的父对象出现的任何地方,并保证原来程序的逻辑以及正确性不变。也就是说在子类实现父类的时候,要遵守父类的行为约定。子类可以改变内部的实现逻辑,但不能改变函数原有的行为约定(比如子类冒出一个父类未知的异常,或者状态码)

特点:

  • 子类能替换父类出现的任何地方;

  • 子类必须严格遵守父类的行为约定(新增的异常、状态码,只有在子类逻辑中触发,不能在父类中触发),以保证原有程序的正确性;

  • 里氏替换原则和多态有点类似

  • 多态是面向对象的一大特性,也是面向对象的一种语法;

  • 多态是一种代码实现的思路

  • 里氏替换原则是一种设计原则,用来指导继承关系中子类应该如何设计;

实现目的:改进已有实现(对父类的代码进行增强)、指导程序开发(类的组织关系)、改进抽象设计;

接口隔离原则 ISP Interface Segregation Principle

定义:调用者(使用者)不应该被强迫依赖它不需要的接口。三种场景:

  • 一组API接口集合:比如dubbo提供的Api,一个接口内可能有好几个方法,我们只需要使用其中一个;

  • 单个接口:比如在我们的系统有一些聚合接口,提供给外部,有新的需求时,可能只用其中一个字段,就直接调接口取了;

  • OOP中的接口概念:主张多继承,不要把一坨都写到一个接口里;

特点:

  • 一个类对另外一个类的依赖应当是建立在最小的接口上;

  • 客户端不应该依赖它不需要的接口方法/功能;

  • 接口实现尽可能的单一,不要依赖不需要的;

  • 接口隔离和单一职责的区别:

  • 单一职责是针对的模块、类、接口的设计;

  • 接口隔离原则提供了一种判断接口的职责是否单一的标准;

实现目的:基于调用者考虑,低耦合、确保最小依赖/调用/使用;

依赖倒置原则

定义:高层模块不要依赖低层模块,高层模块和低层模块应该通过抽象来相互依赖。

在之前的DDD应用框架中,基础设施层就依赖倒置了domain层;

特点:

  • 高层不依赖低层模块,共同依赖同一个抽象

  • 抽象不关注具体的实现细节,具体实现细节依赖于抽象;

实现目的:指导框架层面的设计

迪米特法则 LOD Law of Demeter

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

特点:

  • 不该有直接依赖关系的,不要有依赖;

  • 有依赖的,尽量只依赖必要的接口;

实现目的:基于类关系,高内聚、松耦合

DRY 原则 Don't Repeat Yourself

定义:不要写重复的代码。

特点:

  • 代码复用

  • 减少代码藕合

  • 满足单一职责

  • 模块化

  • 业务与非业务逻辑分离

  • 继承、多态、抽象、封装

  • 应用模板等设计模式将功能拆解为原子方法;

实现目的:代码复用

KISS 原则

定义:尽可能的保持简单

  • Keep It Simple and Stupid.

  • Keep It Short and Simple.

  • Keep It Simple and Straightforward.

特点:

  • 代码足够简单,意味着通俗易懂,bug难隐藏

  • 不要使用同事不懂的技术来实现代码

  • 不要重复造轮子

  • 不要过度优化

实现目的:保持代码的可读性和维护性

转载请注明:我要编程 » 常见设计原则

与本文相关的文章