Su的技术博客

  • 首页
  • 原创
  • 视频
  • Java
  • MySQL
  • DDD
  • 事故复盘
  • 架构方案
  • AI
  • Other
  • 工具
    • AI工具集
    • 工具清单
    • JSON在线格式化
    • JSON在线比较
    • SQL在线格式化
  • 打赏
  • 关于
路很长,又很短
  1. 首页
  2. Java
  3. 正文
                           

【转载】用图讲解SOLID设计原则

2023-10-10 2077点热度 0人点赞 0条评论
用图讲解SOLID设计原则
*All illustrations in this article are by 

Ugonna Thelma

If you are familiar with Object-Oriented Programming, then you’ve probably heard about the SOLID principles.

These five software development principles are guidelines to follow when building software so that it is easier to scale and maintain. They were made popular by a software engineer, Robert C. Martin.

There are so many great articles online about SOLID but I rarely see any examples with pictures. This makes it a bit difficult for visual learners like me to learn while staying engaged.

So the main aim of this article is to get a better understanding of these principles using illustrations and emphasizing the goal for each principle.

You see, some of these principles may look similar but they are not targeting the same goal. It is possible to satisfy one principle while violating the other, even though they are alike.

To make this as simple to follow, I will be using the word “Class” but note that it can also apply to a Function, Method or Module in this article.

Update*
I got some comments about the Open Closed in this article violating the Single Responsibility Principle. Please note that the aim of this article is to explain each of these principles independent of the others.

Also, Responsibilities(or Roles) are different from Actions. In SRP, I used “I am Painter”, in Open-Closed, I used “I can Paint”.

It is important to note this because several actions can be performed to fulfil a responsibility(or role). The class should have one responsibility(SRP) but its functionality that fulfils that responsibility should be open to extend(OCP).

Now, let’s begin!

The SOLID Principles

S — Single Responsibility

A class should have a single responsibility

用图讲解SOLID设计原则

If a Class has many responsibilities, it increases the possibility of bugs because making changes to one of its responsibilities, could affect the other ones without you knowing.

Goal

This principle aims to separate behaviours so that if bugs arise as a result of your change, it won’t affect other unrelated behaviours.

O — Open-Closed

Classes should be open for extension, but closed for modification

用图讲解SOLID设计原则

Changing the current behaviour of a Class will affect all the systems using that Class.

If you want the Class to perform more functions, the ideal approach is to add to the functions that already exist NOT change them.

Goal

This principle aims to extend a Class’s behaviour without changing the existing behaviour of that Class. This is to avoid causing bugs wherever the Class is being used.

L — Liskov Substitution

If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.

用图讲解SOLID设计原则

When a child Class cannot perform the same actions as its parent Class, this can cause bugs.

If you have a Class and create another Class from it, it becomes a parent and the new Class becomes a child. The child Class should be able to do everything the parent Class can do. This process is called Inheritance.

The child Class should be able to process the same requests and deliver the same result as the parent Class or it could deliver a result that is of the same type.

The picture shows that the parent Class delivers Coffee(it could be any type of coffee). It is acceptable for the child Class to deliver Cappucino because it is a specific type of Coffee, but it is NOT acceptable to deliver Water.

If the child Class doesn’t meet these requirements, it means the child Class is changed completely and violates this principle.

Goal

This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.

I — Interface Segregation

Clients should not be forced to depend on methods that they do not use.

用图讲解SOLID设计原则

When a Class is required to perform actions that are not useful, it is wasteful and may produce unexpected bugs if the Class does not have the ability to perform those actions.

A Class should perform only actions that are needed to fulfil its role. Any other action should be removed completely or moved somewhere else if it might be used by another Class in the future.

Goal

This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.

D — Dependency Inversion

- High-level modules should not depend on low-level modules. Both should depend on the abstraction.

- Abstractions should not depend on details. Details should depend on abstractions.

用图讲解SOLID设计原则

Firstly, let’s define the terms used here more simply

High-level Module(or Class): Class that executes an action with a tool.

Low-level Module (or Class): The tool that is needed to execute the action

Abstraction: Represents an interface that connects the two Classes.

Details: How the tool works

This principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.

It also says that both the Class and the interface should not know how the tool works. However, the tool needs to meet the specification of the interface.

Goal

This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.

Summary

So far, we have discussed these five principles and highlighted their goals. They are to help you make your code easy to adjust, extend and test with little to no problems.

Thank you so much for reading. I hope you have a better idea about this topic and you had as much fun reading this as I did writing it.

If you have any questions or suggestions, leave a comment

Author:Ugonna Thelma

Software Engineer, UI Designer, Logo Designer, Childrens book illustrator :)

FROM:https://medium.com/backticks-tildes/the-s-o-l-i-d-principles-in-pictures-b34ce2f1e898

更多文章:

  1. 45 个 Git 经典操作场景,专治不会合代码
  2. 殷浩详解DDD系列 第一讲 - Domain Primitive
  3. DDD系列第五讲:聊聊如何避免写流水账代码
  4. 云音乐贵州机房迁移总体方案回顾
  5. 构建一个布隆过滤器 —— Building a Bloom filter
  6. 优秀开源软件的类,都是怎么命名的?
  7. 我们在顺序消息和事务消息方面的实践
  8. 聊聊spring事务失效的12种场景,太坑了
  9. QQ音乐高可用架构体系
  10. FSM-COLA无状态状态机
标签: 转载 Java 设计原则 OOP solid 依赖注入原则 单一职责原则 开闭原则 接口隔离原则 里氏替换原则
最后更新:2023-10-10

秋天0261

关注Java领域,后端开发、Netty、Zookeeper、Kafka、ES、分布式、微服务、架构等。分享技术干货,架构设计,实战经验等。

打赏 点赞
< 上一篇
下一篇 >

文章评论

razz evil exclaim smile redface biggrin eek confused idea lol mad twisted rolleyes wink cool arrow neutral cry mrgreen drooling persevering
取消回复

广告
文章目录
  • The SOLID Principles
    • S — Single Responsibility
    • O — Open-Closed
    • L — Liskov Substitution
    • I — Interface Segregation
    • D — Dependency Inversion
  • Summary
最新 热点 推荐
最新 热点 推荐
干货 | 论Elasticsearch数据建模的重要性 马蜂窝消息总线——面向业务的消息服务设计 基于 MySQL Binlog 实现可配置的异构数据同步 视频笔记:Google发布Agent2Agent协议 视频笔记:什么是微服务,为什么是微服务? 视频笔记:什么是AI 智能体? 视频笔记:什么是Flink? 如何秒级实现接口间“幂等”补偿:一款轻量级仿幂等数据校正处理辅助工具
Elasticsearch 使用误区之六——富文本内容写入前不清洗基于 MySQL Binlog 实现可配置的异构数据同步马蜂窝消息总线——面向业务的消息服务设计干货 | 论Elasticsearch数据建模的重要性你可以不用RxJava,但必须得领悟它的思想!如何秒级实现接口间“幂等”补偿:一款轻量级仿幂等数据校正处理辅助工具视频笔记:什么是Flink?视频笔记:什么是AI 智能体?
《解构领域驱动设计》读书笔记 浅析设计模式5 -- 责任链模式 富途证券关于2021.10.9凌晨交易中断事故的道歉和回复 什么是Event Sourcing?跟CQRS和DDD有什么关系 聊聊spring事务失效的12种场景,太坑了 干货 | Elasticsearch基础但非常有用的功能之二:模板 ChatGPT之帮我找出Bug! 6.分层架构(译)

CRUD (1) Event Sourcing (1) graphql (1) id (1) NoSQL (1) quarkus (1) rest (1) RocketMQ (2) Spring Boot (1) zk (1) zookeeper (1) 上下文 (1) 事务消息 (1) 二级缓存 (1) 值对象 (1) 关系数据库 (1) 分布式缓存 (1) 原子性 (1) 唯一ID (1) 商品 (1) 多对多 (1) 子域 (1) 字符集 (1) 客户端心跳 (1) 幂等 (2) 干货 (1) 并发 (1) 应用场景 (1) 应用架构图 (1) 康威定律 (2) 异步复制 (1) 微服务架构 (2) 总体方案 (1) 技术方案 (2) 技术架构 (2) 技术架构图 (1) 技能 (1) 持续集成 (1) 支撑域 (1) 故障恢复 (1) 数据架构图 (1) 方案选型 (1) 日记 (1) 服务发现 (1) 服务治理 (1) 服务注册 (2) 机房 (1) 核心域 (1) 泄漏 (1) 洋葱架构 (1) 消息队列 (5) 源码剖析 (1) 灰度发布 (1) 熔断 (1) 生态 (1) 画图工具 (1) 研发团队 (1) 线程 (2) 组织架构 (1) 缓存架构 (1) 编码 (1) 视频 (18) 读写分离 (1) 贵州 (1) 软件设计 (1) 迁移 (1) 通用域 (1) 集群化 (1) 雪花算法 (1) 顺序消息 (1)

推荐链接🔗
  • AI工具集
  • 工具箱🛠️

COPYRIGHT © 2014-2025 verysu.com . ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

粤ICP备15033072号-2

x