因为是刚开始写软件设计相关的文章，这里先大概介绍下，软件设计相关的知识图谱。大概分类的话，
编程范式
软件设计相关原则
- Don’t Repeat Yourself (DRY)
- Keep It Simple, Stupid(KISS)
- Program to an interface, not an implementation
- You Ain’t Gonna Need It (YAGNI)
- Law of Demeter
- 面向对象的 S.O.L.I.D 原则
面向对象设计
设计模式
编程规范
代码重构
从本篇开始，主要先介绍下SOLID五大原则，剩余的设计模式、编程范式 有时间在进行学习整理。
软件设计的本质是设计出可拓展、高质量、可读、可维护的代码
单一职责原则（SRP）是什么
单一职责原则是 Single Responsibility Principle SRP，一个类或者模块只负责一个职责。其实说白就是一个类只应该负责一件事情，这样的话，就可以减少不必要的变化。将类拆分成更加单一、粒度更细的类。
比如一个用户类，但是对应有一些用户的基础信息等，这个时候，我们应该拆分成两个类，一个是用户注册类 User，只保存一些身份证、手机号信息，另外应该有一个User_Info类，保存用户的基本信息。比如身份证照片、地址等等信息。
单一职责原则是为了实现代码高内聚、低耦合、提高代码的复用性、可读性、可维护性
如何判断类是否单一
比如还是以上面的User类来说，如果说在业务前期，那么其实可以在一个用户类中保存所有用户相关的信息，但是随着业务扩张，用户其他信息其实可以进行抽离出来，比如做成一个单独的用户中心，提供整个系统进行使用。所以类是否单一其实需要结合方式的业务场景进行判断。包括在后期的时候进行业务重构。
包括在实际的开发中，接手的一个项目并没有使用Spring进行开发，而是全部new对象的方式，导致某几个类 基本上包含了全部的核心逻辑，差不多有几千行代码，但是也没人敢进行修改，因为变化的话 可能导致别的问题出现。这种其实就需要进行重构。将类进行拆分，按照不同的逻辑功能，拆分成不同的类以及函数功能。
一般来说，如果类的代码行数过多、属性、函数过多，就需要拆分。依赖的类过多等。其实归根结底要理解分离关注点。
不同行为负责的代码放到不同的地方，这样就可以将变化尽可能的聚焦。
小结
关于单一职责原则，其核心的思想是：一个类，只做一件事，并把这件事做好，其只有一个引起它变化的原因。单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申，将职责定义为引起变化的原因，以提高内聚性来减少引起变化的原因。
职责过多，可能引起它变化的原因就越多，这将导致职责依赖，相互之间就产生影响，从而极大地损伤其内聚性和耦合度。单一职责，通常意味着单一的功能，因此不要为一个模块实现过多的功能点，以保证实体只有一个引起它变化的原因
