单一职责(SPR)-创新互联
单一职责最简单的面向对象设计原则，它用于控制类的粒度大小。单一职责原则定义为：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
以一个简单的例子来看单一职责，你会发现其实我们在写代码的过程中基本是在使用着单一职责的。
下图是一个关于用户User类的初始设计方案：
图1 单一职责初始设计方案
在图1中，UserInfo类承担了过多的功能，既包含数据库的连接方法，又包含了用户的查询、创建、删除的方法。如果要在其他类中也需要连接数据库则难以实现代码的复用。无论是修改数据库连接方式还是修改用户相关的方法都需要修改该类，违背了单一职责原则。
下图是按照单一职责原则进行重新设计的方案：
图2 单一职责原则重构后方案
在单一职责原则重构方案中UserInfo可以拆分为如图中三个类：
（1）DbUtil：负责负责连接数据库，包含连接数据库的方法getConnection()。
（2）UserDao：负责操作数据库中的user表，包含对user表的增删改查操作的方法。
（3）UserInfo：负责user信息的生成处理等操作。
以上举了一个简单的例子来说明单一职责原则的使用，但大部分情况下，类里的方法是归为同一类功能，还是归为不相关的两类功能，并不是那么容易判定的。在真实的软件开发中，对于一个类是否职责单一的判定，是很难拿捏的。
public class UserInfo {
private long userId;
private String username;
private String email;
private String telephone;
private long createTime;
private long lastLoginTime;
private String avatarUrl;
private String provinceOfAddress; // 省
private String cityOfAddress; // 市
private String regionOfAddress; // 区
private String detailedAddress; // 详细地址
// ...省略其他属性和方法...
}如上代码，是在一个社交产品中记录用户信息的类，那么这个设计是否符合单一职责原则呢？如果在这个社交产品中，用户的地址信息跟其他信息一样，只是单纯地用来展示，那UserInfo现在的设计就是合理的。但是，如果这个社交产品发展得比较好，之后又在产品中添加了电商的模块，用户的地址信息还会用在电商物流中，那我们最好将地址信息从UserInfo中拆分出来，独立成用户物流信息（或者叫地址信息、收货信息等）。
评价一个类的职责是否足够单一，我们并没有一个非常明确的、可以量化的标准，可以说，这是件非常主观、仁者见仁智者见智的事情。实际上，在真正的软件开发中，我们也没必要过于未雨绸缪，过度设计。所以，我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。
为了满足单一职责原则，是不是把类拆得越细就越好呢？答案是否定的。过度的拆分可能会导致原本只需要修改一处代码的现在需要修改多处，程序代码的可维护性变差。
实际上，不管是应用设计原则还是设计模式，最终的目的还是提高代码的可读性、可扩展性、复用性、可维护性等。我们在考虑应用某一个设计原则是否合理的时候，也可以以此作为最终的考量标准。
你是否还在寻找稳定的海外服务器提供商？创新互联www.cdcxhl.cn海外机房具备T级流量清洗系统配攻击溯源，准确流量调度确保服务器高可用性，企业级服务器适合批量采购，新人活动首月15元起，快前往官网查看详情吧
文章标题：单一职责(SPR)-创新互联
文章路径：http://6mz.cn/article/dppgis.html