文章目录
前言
面向对象设计原则是学习设计模式的基础，每一种设计模式都符合某一种或多种面向对象设计原则。通过在软件开发中适用这些原则，可以提高软件的可维护性和可复用性，让我们可以设计出更加灵活也更容易拓展的软件系统，实现可维护性服用的目标
面向对象设计原则包括：
| 设计原则名称 | 设计原则简介 | 重要性 |
|---|---|---|
| 单一职责原则 | 类的职责要单一，不能将太多的职责放在一个类中 | ★★★★☆ |
| 开闭原则 | 软件实体对拓展是开放的，但对修改是关闭的，即在不修改一个软件实体的基础上去拓展其功能 | ★★★★★ |
| 里氏替换原则 | 在软件系统中，一个可以接受基类对象的地方必然可以接受一个子类对象 | ★★★★☆ |
| 依赖倒转原则 | 要针对抽象层编程，而不要针对具体类变成 | ★★★★★ |
| 接口隔离原则 | 使用多个专门的接口取代一个统一的接口 | ★★☆☆☆ |
| 合成复用原则 | 在复用功能时，应该尽量多使用组合和聚合关联关系，尽量少使用甚至不使用继承关系 | ★★★★☆ |
| 迪米特法则 | 一个软件实体对其他实体的引用越少越好，或者说如果两个类不必彼此直接通信，那么这两个类就不应该直接发生通信，而是通过引入第三者发生间接交互 | ★★★☆☆ |
一、单一职责原则定义
单一职责原则（Single Responsibility Principle, SRP）定义：一个对象应该只包含单一的职责，并且该职责被完整的封装在一个类中。或者被定义为：就一个类而言，应该仅有一个引起它改变的原因
二、单一职责原则分析
一个类不能太“累”！在软件系统中，一个类（大到模块，小到方法）承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。
单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但又最难运用的原则
三、单一职责原则实例
拿登录的例子来说，类图如下：
其中：
- getConnection：是获取数据库链接的方法
- findUser()：是从数据库中查询用户是否存在
根据单一职责原则来说，这个登录类应该只做登录相关的事情，而链接数据库、从数据库查询这些功能不需要这个登录类来做，所以需要对这些功能进行拆分
拆分了三个类：
-
LoginClass：只做登录相关逻辑的类 -
UserDAO：负责用户表的增删改查，封装了用户表的全部操作方法，而登录功能本质上就是查询用户表的一个过程 -
DBUtil：负责数据库的连接的工具类，该类封装着多个数据库的操作
根据单一职责原则重构的类图为：
通过单一职责原则重构后将使得系统中类的个数增加，但是类的复用性得到了提升。比如，DBUtil类可以被多个DAO类（操作数据库的类）使用，而UserDAO类呢，可以在多个需要获取用户或者对用户进行添加修改的功能中被使用，例如添加用户、删除用户、修改用户密码等。