之前大概花了8篇Blog的篇幅学习了面向对象的设计思想，从今天起继续学习设计原则，什么是设计原则呢？回到最初的目标：【Java设计模式 学习目标及大纲】高质量代码的标准及实现路径

在这篇Blog里我们明确了什么是高质量的代码：易维护、易读、易扩展、灵活、简洁、可复用、可测试，也知道高质量代码的达成路径工具箱：面向对象设计思想是基本指导思想，是很多设计原则、设计模式的实现基础；设计原则是代码设计的抽象经验总结、是设计模式设计的指导原则；设计模式是代码设计的一套具体解决方案或设计思路，主要用来提高代码可扩展性；编程规范是一套可执行的代码编写规范，主要用来提高代码的可读性；代码重构依赖面向对象设计思想、设计原则、设计模式、编程规范实现，主要用来提高代码的可维护性。

• 面向对象设计思想因为其具有丰富的特性（封装、抽象、继承、多态），可以实现很多复杂的设计思路，是很多设计原则、设计模式等编码实现的基础。理论支撑，实现基础，核心思想：编程规范及代码组织
• 设计原则是指导我们代码设计的一些经验总结，对于某些场景下，是否应该应用某种设计模式，具有指导意义。比如，“开闭原则”是很多设计模式（策略、模板等）的指导原则。代码组织：高质量编程的道
• 设计模式是针对软件开发中经常遇到的一些设计问题，总结出来的一套解决方案或者设计思路。应用设计模式的主要目的是提高代码的可扩展性。从抽象程度上来讲，设计原则比设计模式更抽象。设计模式更加具体、更加可执行。代码组织：高质量编程的术
• 编程规范主要解决的是代码的可读性问题。编码规范相对于设计原则、设计模式，更加具体、更加偏重代码细节、更加能落地。持续的小重构依赖的理论基础主要就是编程规范。编程规范
• 代码重构作为保持代码质量不下降的有效手段，利用的就是面向对象、设计原则、设计模式、编码规范这些理论。高质量编程实践

实际上，面向对象、设计原则、设计模式、编程规范、代码重构，这五者都是保持或者提高代码质量的方法论，本质上都是服务于编写高质量代码这一件事的。也可以这么理解：1个设计思想、6个设计原则、23个设计模式、一套编程规范，在合适的时机进行代码重构，时刻保证和提高代码的质量

之所以每一个大的模块开始和结束都要提这个目标就是因为，本专栏全部内容都是通过不同的路径最终达成这个目标，全部思想及技能都是围绕个目标展开的。

上一部分详细学习了面向对象设计思想，有了面向对象设计思想这个基础后，我们知道了面向对象和面向过程的区别；明确了面向对象代码的组织形式是类和对象，也了解了面向对象语法支持的四大特性；熟悉了一些特殊类的使用，例如抽象类和接口；明白了一些基于设计思想的一些最佳用法，诸如：组合优于继承使用，基于接口而非实现编程；回顾面向对象编程的定义：

• 以类或对象作为组织代码的基本单元，并将封装、抽象、继承、多态四个特性，作为代码设计和实现的基石

那么如何让编写出来的代码更加高质量，就在于我们如何用好面向对象四大特性，用最优的方式组织类和对象。设计原则就是提供这样的指导意见的。

SOLID 原则

实际上，SOLID 原则并非单纯的 1 个原则，而是由 5 个设计原则组成的，它们分别是：SRP单一职责原则（the single responsibility principle ）、OCP开闭原则（the open closed principle）、LSP里氏替换原则（the liskov substitution principle）、ISP接口独立原则（the interface segregation principle）、DIP依赖倒置原则（the dependency inversion principle），依次对应 SOLID 中的 S、O、L、I、D 这 5 个英文字母

理解单一职责原则

单一职责原则的英文是 Single Responsibility Principle，缩写为 SRP。这个原则的英文描述是这样的：A class or module should have a single responsibility。翻译成中文就是：一个类或者模块只负责完成一个职责（或者功能），也就是说，不要设计大而全的类，要设计粒度小、功能单一的类。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类。

运用单一职责原则

分别从主观上的业务发展和客观的一些规则去理解单一职责原则。

主观运用单一职责原则

业务并非一成不变的，业务一直在发展，而我们对类或模块是否单一的看法也并非一成不变。举个例子，对于用户信息维护这个类来讲：

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 中拆分出来，独立成用户物流信息（或者叫地址信息、收货信息等）

当然随着业务的发展，如果做这个社交产品的公司发展得越来越好，公司内部又开发出了很多其他产品（可以理解为其他 App）。公司希望支持统一账号系统，也就是用户一个账号可以在公司内部的所有产品中登录。这个时候，我们就需要继续对 UserInfo 进行拆分，将跟身份认证相关的信息（比如，email、telephone 等）抽取成独立的类。

所以一开始设计要尽量避免过度设计，因为你根本不知道业务未来会发展成什么样，能做的最好只是提前预留好扩展点，静候业务发展然后实时做出调整，我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的 持续重构

客观运用单一职责原则

当然对于当下业务场景如果看法也是模棱两可，那么可以简单参考下如下几条原则，下面这几条判断原则，比起很主观地去思考类是否职责单一，要更有指导意义、更具有可执行性：

• 类中的代码行数、函数或属性过多，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分； 从另一个角度来看，当一个类的代码，可读性非常差，实现某个功能时不知道该用哪个函数，想用哪个函数翻半天都找不到了，只用到一个小功能要引入整个类（类中包含很多无关此功能实现的函数）的时候，这就说明类的行数、函数、属性过多了
• 类依赖的其他类过多，或者依赖类的其他类过多（被其它类使用），不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
• 私有方法过多，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
• 比较难给类起一个合适名字，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，这就说明类的职责定义得可能不够清晰；
• 类中大量的方法都是集中操作类中的某几个属性，比如，在 UserInfo 例子中，如果一半的方法都是在操作 address 信息，那就可以考虑将这几个属性和对应的方法拆分出来。

当然以上指标中的过多、几个都是一个不确定的量词，这个数量该是多少，则仁者见仁智者见智，有时候仅仅是写代码的一些感觉。

避免单一职责原则思维误区

为了满足单一职责原则，是不是把类拆得越细就越好呢？答案是否定的。通过一个例子来解释一下。Serialization 类实现了一个简单协议的序列化和反序列功能，具体代码如下：

/**
 * Protocol format: identifier-string;{gson string}
 * For example: UEUEUE;{"a":"A","b":"B"}
 */
public class Serialization {
  private static final String IDENTIFIER_STRING = "UEUEUE;";
  private Gson gson;
  public Serialization() {
    this.gson = new Gson();
  }
  public String serialize(Map<String, String> object) {
    StringBuilder textBuilder = new StringBuilder();
    textBuilder.append(IDENTIFIER_STRING);
    textBuilder.append(gson.toJson(object));
    return textBuilder.toString();
  }
  public Map<String, String> deserialize(String text) {
    if (!text.startsWith(IDENTIFIER_STRING)) {
        return Collections.emptyMap();
    }
    String gsonStr = text.substring(IDENTIFIER_STRING.length());
    return gson.fromJson(gsonStr, Map.class);
  }
}

如果我们想让类的职责更加单一，我们对 Serialization 类进一步拆分，拆分成一个只负责序列化工作的 Serializer 类和另一个只负责反序列化工作的 Deserializer 类。拆分后的具体代码如下所示

public class Serializer {
  private static final String IDENTIFIER_STRING = "UEUEUE;";
  private Gson gson;
  public Serializer() {
    this.gson = new Gson();
  }
  public String serialize(Map<String, String> object) {
    StringBuilder textBuilder = new StringBuilder();
    textBuilder.append(IDENTIFIER_STRING);
    textBuilder.append(gson.toJson(object));
    return textBuilder.toString();
  }
}
public class Deserializer {
  private static final String IDENTIFIER_STRING = "UEUEUE;";
  private Gson gson;
  public Deserializer() {
    this.gson = new Gson();
  }
  public Map<String, String> deserialize(String text) {
    if (!text.startsWith(IDENTIFIER_STRING)) {
        return Collections.emptyMap();
    }
    String gsonStr = text.substring(IDENTIFIER_STRING.length());
    return gson.fromJson(gsonStr, Map.class);
  }
}

虽然经过拆分之后，Serializer 类和 Deserializer 类的职责更加单一了，但也随之带来了新的问题。如果我们修改了协议的格式，数据标识从“UEUEUE”改为“DFDFDF”，或者序列化方式从 JSON 改为了 XML，那 Serializer 类和 Deserializer 类都需要做相应的修改，代码的内聚性显然没有原来 Serialization 高了。而且，如果我们仅仅对 Serializer 类做了协议修改，而忘记了修改 Deserializer 类的代码，那就会导致序列化、反序列化不匹配，程序运行出错，也就是说，拆分之后，代码的可维护性变差了

总结一下

单一职责原则是为了实现代码高内聚（功能相关高内聚）、低耦合（功能无关低耦合），提高代码的可复用性、可读性、可维护性。具体怎么拆分主观上依据对业务发展的认知和场景的分析持续重构，客观上依据几条可执行规则：代码的行数、属性、方法不要过多；类依赖与被依赖的程度较低；私有的通用方法不能过多；类要比较好命名，见名之意；类的属性操作比较均衡。虽然单一职责原则原则好，可不要单纯为了更单一去拆分，否则本来内聚的功能被拆分了后代码的可维护性就会变的很差。