六大设计模式原则-单一职责原则

热衷学习，热衷生活！😄

沉淀、分享、成长，让自己和他人都能有所收获！😄

一、单一职责原则定义

单一职责原则是面向对象五个基本原则（SOLID）之一，也是最简单的面向对象设计原则，用于控制类的颗粒大小。单一职责定义如下：

单一职责原则（SRP：Single responsibility principle）：一个类只负责一个功能领域中的相应职责，也可以定义为：一个类应该只有一个发生变化的原因。

二、单一职责原则描述

单一职责原则告诉我们：一个类不能太”累”，在一个系统中，如果一个类（大到模块，小到方法）承担的职责越多，那么它被复用的可能性就越小，而且耦合度很高，如果当其中一个职责发生改变时，可能会影响到其他职责，所以我们在设计开发的时候应该讲这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职业总是同时发生变化则可将他们封装在同一类中。

单一职责原则是实现高内聚、低耦合的指导方针，它是最简单但是又是最难运用的原则，需要设计人员发现类的不同职责并将其进行分离，而发现类的多重职责需要设计人员具有较强的分析设计能力和相关的实践经验。（希望我们都能成为这类人，干吧得~）

三、单一职责原则栗子

不满足单一职责原则

public class CustomerDataChar {
    public Connection getConnection(){
        // 获取数据库连接
    }
    
    public List<Customer> findCustomers(){
        // 查询客户列表
    }
    
    public void createChar(){
        // 创建图表
    }
    
    public void displayChar(){
        // 显示图表
    }
}

现在有一个类CustomerDataChar，包含了4个方法，分别是：

getConnection 获取数据库连接。
findCustomers 用于查询用户列表。
createChar 用于创建图表。
displayChar 用于显示图表。

CustomerDataChar类承担了太多职责，包含了与数据库相关的方法，又包含了图表生成和显示的相关方法。如果其他类中也需要获取数据库连接或者调用findCustomers方法，则难以实现代码的重用。无论是要修改数据库连接方法还是修改图表显示方式都要修改此类，不止一个发生变化的原因，违背了单一职责原则。

优化，满足单一职责原则

public class DBUtil {
    public Connection getConnection(){
        // 获取数据库连接
    }
}

public class CustomerDao {
    
    private DBUtil dButil;
    
    public List<Customer> findCustomers(){
        // 查询客户列表
    }
}

public class CustomerDataChar {
    
    private CustomDao customDao;
    
    public void createChar(){
        // 创建图表
    }
    
    public void displayChar(){
        // 显示图表
    }
}