1. 单一职责原则
来自：理论一：对于单一职责原则，如何判定某个类的职责是否够“单一”？
1.1 如何理解单一职责原则（SRP）？
单一职责原则的英文是 Single Responsibility Principle，缩写为 SRP。这个原则的英文描述是这样的：A class or module should have a single responsibility。如果我们把它翻译成中文，那就是：一个类或者模块只负责完成一个职责（或者功能） 。
单一职责原则的定义描述非常简单，也不难理解。一个类只负责完成一个职责或者功能 。也就是说，不要设计大而全的类，要设计粒度小、功能单一的类 。换个角度来讲就是，一个类包含了两个或者两个以上业务不相干的功能，那我们就说它职责不够单一，应该将它拆分成多个功能更加单一、粒度更细的类 。
比如，一个类里既包含订单的一些操作，又包含用户的一些操作。而订单和用户是两个独立的业务领域模型，我们将两个不相干的功能放到同一个类中，那就违反了单一职责原则。为了满足单一职责原则，我们需要将这个类拆分成两个粒度更细、功能更加单一的两个类：订单类和用户类。
1.2 如何判断类的职责是否足够单一？
在真实的软件开发中，对于一个类是否职责单一的判定，是很难拿捏的 。
我举一个更加贴近实际的例子来给你解释一下。
在一个社交产品中，我们用下面的 UserInfo 类来记录用户的信息。
复制
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 类中，所占的比重比较高，可以继续拆分成独立的 UserAddress 类，UserInfo 只保留除 Address 之外的其他信息，拆分之后的两个类的职责更加单一。
哪种观点更对呢？实际上，要从中做出选择，我们不能脱离具体的应用场景。如果在这个社交产品中，用户的地址信息跟其他信息一样，只是单纯地用来展示，那 UserInfo 现在的设计就是合理的。但是，如果这个社交产品发展得比较好，之后又在产品中添加了电商的模块，用户的地址信息还会用在电商物流中 ，那我们最好将地址信息从 UserInfo 中拆分出来，独立成用户物流信息（或者叫地址信息、收货信息等）。
我们再进一步延伸一下。如果做这个社交产品的公司发展得越来越好，公司内部又开发出了很多其他产品（可以理解为其他 App）。公司希望支持统一账号系统，也就是用户一个账号可以在公司内部的所有产品中登录。这个时候，我们就需要继续对 UserInfo 进行拆分，将跟身份认证相关的信息（比如，email、telephone 等）抽取成独立的类 。
从刚刚这个例子，我们可以总结出，不同的应用场景、不同阶段的需求背景下，对同一个类的职责是否单一的判定，可能都是不一样的 。在某种应用场景或者当下的需求背景下，一个类的设计可能已经满足单一职责原则了，但如果换个应用场景或着在未来的某个需求背景下，可能就不满足了，需要继续拆分成粒度更细的类。
除此之外，从不同的业务层面去看待同一个类的设计，对类是否职责单一，也会有不同的认识 。比如，例子中的 UserInfo 类。如果我们从“用户”这个业务层面来看，UserInfo 包含的信息都属于用户，满足职责单一原则。如果我们从更加细分的“用户展示信息”“地址信息”“登录认证信息”等等这些更细粒度的业务层面来看，那 UserInfo 就应该继续拆分。
实际上，在真正的软件开发中，我们也没必要过于未雨绸缪，过度设计 。所以，我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的持续重构 。
下面这几条判断原则，比起很主观地去思考类是否职责单一，要更有指导意义、更具有可执行性：
类中的代码行数、函数或属性过多 ，会影响代码的可读性和可维护性，我们就需要考虑对类进行拆分；
类依赖的其他类过多，或者依赖类的其他类过多 ，不符合高内聚、低耦合的设计思想，我们就需要考虑对类进行拆分；
私有方法过多 ，我们就要考虑能否将私有方法独立到新的类中，设置为 public 方法，供更多的类使用，从而提高代码的复用性；
比较难给类起一个合适名字 ，很难用一个业务名词概括，或者只能用一些笼统的 Manager、Context 之类的词语来命名，这就说明类的职责定义得可能不够清晰；
类中大量的方法都是集中操作类中的某几个属性 ，比如，在 UserInfo 例子中，如果一半的方法都是在操作 address 信息，那就可以考虑将这几个属性和对应的方法拆分出来。
实际上， 从另一个角度来看，当一个类的代码，读起来让你头大了，实现某个功能时不知道该用哪个函数了，想用哪个函数翻半天都找不到了，只用到一个小功能要引入整个类（类中包含很多无关此功能实现的函数）的时候，这就说明类的行数、函数、属性过多了 。实际上，等你做多项目了，代码写多了，自然就知道多少行代码才算是行数过多呢？多少个函数、属性才称得上过多了。
1.3 类的职责是否设计得越单一越好？
为了满足单一职责原则，是不是把类拆得越细就越好呢？答案是否定的。
我们还是通过一个例子来解释一下。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 类的代码，那就会导致序列化、反序列化不匹配，程序运行出错，也就是说，拆分之后，代码的可维护性变差了 。
实际上，不管是应用设计原则还是设计模式，最终的目的还是提高代码的可读性、可扩展性、复用性、可维护性等 。
我们在考虑应用某一个设计原则是否合理的时候，也可以以此作为最终的考量标准。
1.4 总结
单一职责原则是指一个类只负责完成一个职责或者功能 ，不要设计大而全的类，要设计粒度小，功能单一的类。单一职责原则是为了实现代码高内聚、低耦合，提高代码的复用性、可读性、可维护性 。
如何判断职责是否单一：代码行数，依赖是否过多，私有方法，集中操作某几个属性。
是否设计的越单一越好，肯定不是的，还需要考虑可维护性。
2. 开闭原则
来自：理论二：如何做到“对扩展开放、修改关闭”？扩展和修改各指什么？
怎样的代码改动才被定义为扩展？怎样的代码改动才被定义为修改？怎么才算满足或违反开闭原则？修改代码就一定意味着违反开闭原则吗？如何在项目中灵活地应用开闭原则，以避免在追求扩展性的同时影响到代码的可读性？
扩展性是代码质量最重要的衡量标准之一 。在 23 种经典设计模式中，大部分设计模式都是为了解决代码的扩展性问题而存在的，主要遵从的设计原则就是开闭原则。
2.1 如何理解“对扩展开放、修改关闭”？
对扩展开放，对修改关闭的意思是：添加一个新的功能应该是，在已有代码基础上扩展代码（新增模块、类、方法等），而非修改已有代码（修改模块、类、方法等） 。
例子：这是一段 API 接口监控告警的代码。其中，AlertRule 存储告警规则，可以自由设置。Notification 是告警通知类，支持邮件、短信、微信、手机等多种通知渠道。NotificationEmergencyLevel 表示通知的紧急程度，包括 SEVERE（严重）、URGENCY（紧急）、NORMAL（普通）、TRIVIAL（无关紧要），不同的紧急程度对应不同的发送渠道。
复制
public class Alert {
private AlertRule rule;
private Notification notification;
public Alert ( AlertRule rule , Notification notification) {
this . rule = rule;
this . notification = notification;
}
public void check ( String api , long requestCount , long errorCount , long durationOfSeconds) {
long tps = requestCount / durationOfSeconds;
if (tps > rule . getMatchedRule (api) . getMaxTps ()) {
notification . notify ( NotificationEmergencyLevel . URGENCY , "..." );
}
if (errorCount > rule . getMatchedRule (api) . getMaxErrorCount ()) {
notification . notify ( NotificationEmergencyLevel . SEVERE , "..." );
}
}
} 现在，如果我们需要添加一个功能（考虑扩展性），当每秒钟接口超时请求个数，超过某个预先设置的最大阈值时，我们也要触发告警发送通知。这个时候主要的改动有两处：第一处是修改 check() 函数的入参，添加一个新的统计数据 timeoutCount，表示超时接口请求数；第二处是在 check() 函数中添加新的告警逻辑。具体的代码改动如下所示：
复制
public class Alert {
// ...省略AlertRule/Notification属性和构造函数...
// 改动一：添加参数timeoutCount
public void check ( String api , long requestCount , long errorCount , long timeoutCount , long durationOfSeconds) {
long tps = requestCount / durationOfSeconds;
if (tps > rule . getMatchedRule (api) . getMaxTps ()) {
notification . notify ( NotificationEmergencyLevel . URGENCY , "..." );
}
if (errorCount > rule . getMatchedRule (api) . getMaxErrorCount ()) {
notification . notify ( NotificationEmergencyLevel . SEVERE , "..." );
}
// 改动二：添加接口超时处理逻辑
long timeoutTps = timeoutCount / durationOfSeconds;
if (timeoutTps > rule . getMatchedRule (api) . getMaxTimeoutTps ()) {
notification . notify ( NotificationEmergencyLevel . URGENCY , "..." );
}
}
} 这样的代码修改实际上存在挺多问题的。
一方面，我们对接口进行了修改，这就意味着调用这个接口的代码都要做相应的修改。
另一方面，修改了 check() 函数，相应的单元测试都需要修改（关于单元测试的内容我们在重构那部分会详细介绍）。
上面的代码改动是基于修改 的方式来实现新功能的。如果我们遵循开闭原则，也就是“对扩展开放、对修改关闭”。那如何通过扩展 的方式，来实现同样的功能呢？
我们先重构一下之前的 Alert 代码，让它的扩展性更好一些。重构的内容主要包含两部分：
第一部分是将 check() 函数的多个入参封装成 ApiStatInfo 类；
第二部分是引入 handler 的概念，将 if 判断逻辑分散在各个 handler 中。
具体的代码实现如下所示：
复制
public class Alert {
private List < AlertHandler > alertHandlers = new ArrayList <>();
public void addAlertHandler ( AlertHandler alertHandler) {
this . alertHandlers . add (alertHandler);
}
public void check ( ApiStatInfo apiStatInfo) {
for ( AlertHandler handler : alertHandlers) {
handler . check (apiStatInfo);
}
}
}
public class ApiStatInfo { //省略constructor/getter/setter方法
private String api;
private long requestCount;
private long errorCount;
private long durationOfSeconds;
}
public abstract class AlertHandler {
protected AlertRule rule;
protected Notification notification;
public AlertHandler ( AlertRule rule , Notification notification) {
this . rule = rule;
this . notification = notification;
}
public abstract void check ( ApiStatInfo apiStatInfo);
}
public class TpsAlertHandler extends AlertHandler {
public TpsAlertHandler ( AlertRule rule , Notification notification) {
super(rule , notification);
}
@ Override
public void check ( ApiStatInfo apiStatInfo) {
long tps = apiStatInfo . getRequestCount () / apiStatInfo . getDurationOfSeconds ();
if (tps > rule . getMatchedRule ( apiStatInfo . getApi ()) . getMaxTps ()) {
notification . notify ( NotificationEmergencyLevel . URGENCY , "..." );
}
}
}
public class ErrorAlertHandler extends AlertHandler {
public ErrorAlertHandler ( AlertRule rule , Notification notification){
super(rule , notification);
}
@ Override
public void check ( ApiStatInfo apiStatInfo) {
if ( apiStatInfo . getErrorCount () > rule . getMatchedRule ( apiStatInfo . getApi ()) . getMaxErrorCount ()) {
notification . notify ( NotificationEmergencyLevel . SEVERE , "..." );
}
}
} 其中，ApplicationContext 是一个单例类，负责 Alert 的创建、组装（alertRule 和 notification 的依赖注入）、初始化（添加 handlers）工作。
复制
public class ApplicationContext {
private AlertRule alertRule;
private Notification notification;
private Alert alert;
public void initializeBeans () {
alertRule = new AlertRule( /*.省略参数.*/ ) ; //省略一些初始化代码
notification = new Notification( /*.省略参数.*/ ) ; //省略一些初始化代码
alert = new Alert() ;
alert . addAlertHandler ( new TpsAlertHandler(alertRule , notification) );
alert . addAlertHandler ( new ErrorAlertHandler(alertRule , notification) );
}
public Alert getAlert () { return alert; }
// 饿汉式单例
private static final ApplicationContext instance = new ApplicationContext() ;
private ApplicationContext () {
initializeBeans() ;
}
public static ApplicationContext getInstance () {
return instance;
}
}
public class Demo {
public static void main ( String [] args) {
ApiStatInfo apiStatInfo = new ApiStatInfo() ;
// ...省略设置apiStatInfo数据值的代码
ApplicationContext . getInstance () . getAlert () . check (apiStatInfo);
}
} 主要的改动有下面四处。
第一处改动是：在 ApiStatInfo 类中添加新的属性 timeoutCount。
第二处改动是：添加新的 TimeoutAlertHander 类。
第三处改动是：在 ApplicationContext 类的 initializeBeans() 方法中，往 alert 对象中注册新的 timeoutAlertHandler。
第四处改动是：在使用 Alert 类的时候，需要给 check() 函数的入参 apiStatInfo 对象设置 timeoutCount 的值。
改动之后的代码如下所示：
复制
public class Alert { // 代码未改动... }
public class ApiStatInfo { //省略constructor/getter/setter方法
private String api;
private long requestCount;
private long errorCount;
private long durationOfSeconds;
private long timeoutCount; // 改动一：添加新字段
}
public abstract class AlertHandler { //代码未改动... }
public class TpsAlertHandler extends AlertHandler { //代码未改动...}
public class ErrorAlertHandler extends AlertHandler { //代码未改动...}
// 改动二：添加新的handler
public class TimeoutAlertHandler extends AlertHandler { //省略代码...}
public class ApplicationContext {
private AlertRule alertRule;
private Notification notification;
private Alert alert;
public void initializeBeans () {
alertRule = new AlertRule( /*.省略参数.*/ ) ; //省略一些初始化代码
notification = new Notification( /*.省略参数.*/ ) ; //省略一些初始化代码
alert = new Alert() ;
alert . addAlertHandler ( new TpsAlertHandler(alertRule , notification) );
alert . addAlertHandler ( new ErrorAlertHandler(alertRule , notification) );
// 改动三：注册handler
alert . addAlertHandler ( new TimeoutAlertHandler(alertRule , notification) );
}
//...省略其他未改动代码...
}
public class Demo {
public static void main ( String [] args) {
ApiStatInfo apiStatInfo = new ApiStatInfo() ;
// ...省略apiStatInfo的set字段代码
apiStatInfo . setTimeoutCount ( 289 ); // 改动四：设置tiemoutCount值
ApplicationContext . getInstance () . getAlert () . check (apiStatInfo);
} 重构之后的代码更加灵活和易扩展 。如果我们要想添加新的告警逻辑，只需要基于扩展的方式创建新的 handler 类即可，不需要改动原来的 check() 函数的逻辑。而且我们只需要为新的 handler 类添加单元测试，老的单元测试都不会失败，也不用修改。
2.2 修改代码就意味着违背开闭原则吗？
从开闭原则的定义中，我们可以看出，开闭原则可以应用在不同粒度的代码中，可以是模块，也可以类，还可以是方法（及其属性）。同样一个代码改动，在粗代码粒度下，被认定为“修改”，在细代码粒度下，又可以被认定为“扩展” 。
实际上，我们也没必要纠结某个代码改动是“修改”还是“扩展”，更没必要太纠结它是否违反“开闭原则”。我们回到这条原则的设计初衷：只要它没有破坏原有的代码的正常运行，没有破坏原有的单元测试，我们就可以说，这是一个合格的代码改动 。
而且，我们要认识到，添加一个新功能，不可能任何模块、类、方法的代码都不“修改”，这个是做不到的。类需要创建、组装、并且做一些初始化操作，才能构建成可运行的的程序，这部分代码的修改是在所难免的。我们要做的是尽量让修改操作更集中、更少、更上层（越到下层应该是越稳定的），尽量让最核心、最复杂的那部分逻辑代码满足开闭原则 。
2.3 如何做到“对扩展开放、修改关闭”？
实际上，开闭原则讲的就是代码的扩展性问题，是判断一段代码是否易扩展的“金标准”。如果某段代码在应对未来需求变化的时候，能够做到“对扩展开放、对修改关闭”，那就说明这段代码的扩展性比较好。
为了尽量写出扩展性好的代码，我们要时刻具备扩展意识、抽象意识、封装意识 。
在写代码的时候后，我们要多花点时间往前多思考一下，这段代码未来可能有哪些需求变更 、如何设计代码结构，事先留好扩展点，以便在未来需求变更的时候，不需要改动代码整体结构、做到最小代码改动的情况下，新的代码能够很灵活地插入到扩展点上，做到“对扩展开放、对修改关闭”。
还有，在识别出代码可变部分和不可变部分之后，我们要将可变部分封装起来，隔离变化，提供抽象化的不可变接口，给上层系统使用。当具体的实现发生变化的时候，我们只需要基于相同的抽象接口，扩展一个新的实现，替换掉老的实现即可，上游系统的代码几乎不需要修改 。
在众多的设计原则、思想、模式中，最常用来提高代码扩展性的方法有：多态、依赖注入、基于接口而非实现编程，以及大部分的设计模式 （比如，装饰、策略、模板、职责链、状态等）。
比如，我们代码中通过 Kafka 来发送异步消息 。对于这样一个功能的开发，我们要学会将其抽象成一组跟具体消息队列（Kafka）无关的异步消息接口。所有上层系统都依赖这组抽象的接口编程，并且通过依赖注入的方式来调用 。当我们要替换新的消息队列的时候，比如将 Kafka 替换成 RocketMQ，可以很方便地拔掉老的消息队列实现，插入新的消息队列实现。具体代码如下所示：
复制
// 这一部分体现了抽象意识
public interface MessageQueue { //... }
public class KafkaMessageQueue implements MessageQueue { //... }
public class RocketMQMessageQueue implements MessageQueue { //...}
public interface MessageFromatter { //... }
public class JsonMessageFromatter implements MessageFromatter { //...}
public class ProtoBufMessageFromatter implements MessageFromatter { //...}
public class Demo {
private MessageQueue msgQueue; // 基于接口而非实现编程
public Demo ( MessageQueue msgQueue) { // 依赖注入
this . msgQueue = msgQueue;
}
// msgFormatter：多态、依赖注入
public void sendNotification ( Notification notification , MessageFormatter msgFormatter) {
//...
}
} 2.4 如何在项目中灵活应用开闭原则？
最合理的做法是，对于一些比较确定的、短期内可能就会扩展 ，或者需求改动对代码结构影响比较大的情况，或者实现成本不高的扩展点，在编写代码的时候之后，我们就可以事先做些扩展性设计。但对于一些不确定未来是否要支持的需求 ，或者实现起来比较复杂的扩展点，我们可以等到有需求驱动的时候，再通过重构代码的方式来支持扩展的需求。
而且，开闭原则也并不是免费的。有些情况下，代码的扩展性会跟可读性相冲突 。比如，我们之前举的 Alert 告警的例子。为了更好地支持扩展性，我们对代码进行了重构，重构之后的代码要比之前的代码复杂很多，理解起来也更加有难度。很多时候，我们都需要在扩展性和可读性之间做权衡 。在某些场景下，代码的扩展性很重要，我们就可以适当地牺牲一些代码的可读性；在另一些场景下，代码的可读性更加重要，那我们就适当地牺牲一些代码的可扩展性。
2.5 总结
首先需要对业务比较熟悉，知道将来会有哪些扩展点，但是对于那种暂时想不到有其他扩展点，也不必过度设计，同时需要考虑可读性和扩展性。
提高扩展性的方法主要有依赖注入，面向接口编程，多态以及其他设计模式。
正确理解扩展和修改，只要没有破坏原有代码的正常运行，不破坏原有的测试，这样就是一个合格的改动。另外，修改一般发生在上层模块，越往底层越稳定，一般不会修改，如果经常修改底层代码，说明设计不合理。
3. 里式替换原则
来自：理论三：里式替换（LSP）跟多态有何区别？哪些代码违背了LSP？
3.1 如何理解“里式替换原则”？
概念：子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏 。
如下代码中，父类 Transporter 使用 org.apache.http 库中的 HttpClient 类来传输网络数据。子类 SecurityTransporter 继承父类 Transporter，增加了额外的功能，支持传输 appId 和 appToken 安全认证信息。
复制
public class Transporter {
private HttpClient httpClient;
public Transporter ( HttpClient httpClient) {
this . httpClient = httpClient;
}
public Response sendRequest ( Request request) {
// ...use httpClient to send request
}
}
public class SecurityTransporter extends Transporter {
private String appId;
private String appToken;
public SecurityTransporter ( HttpClient httpClient , String appId , String appToken) {
super(httpClient);
this . appId = appId;
this . appToken = appToken;
}
@ Override
public Response sendRequest ( Request request) {
if ( StringUtils . isNotBlank (appId) && StringUtils . isNotBlank (appToken)) {
request . addPayload ( "app-id" , appId);
request . addPayload ( "app-token" , appToken);
}
return super . sendRequest (request);
}
}
public class Demo {
public void demoFunction ( Transporter transporter) {
Reuqest request = new Request() ;
//...省略设置request中数据值的代码...
Response response = transporter . sendRequest (request);
//...省略其他逻辑...
}
}
// 里式替换原则
Demo demo = new Demo() ;
demo . demofunction ( new SecurityTransporter( /*省略参数*/ ) ;); 在上面的代码中，子类 SecurityTransporter 的设计完全符合里式替换原则，可以替换父类出现的任何位置，并且原来代码的逻辑行为不变且正确性也没有被破坏。
下面这种就是不符合里式替换原则，如果 appId 或者 appToken 没有设置，则直接抛出 NoAuthorizationRuntimeException 未授权异常。
复制
// 改造前：
public class SecurityTransporter extends Transporter {
//...省略其他代码..
@ Override
public Response sendRequest ( Request request) {
if ( StringUtils . isNotBlank (appId) && StringUtils . isNotBlank (appToken)) {
request . addPayload ( "app-id" , appId);
request . addPayload ( "app-token" , appToken);
}
return super . sendRequest (request);
}
}
// 改造后：
public class SecurityTransporter extends Transporter {
//...省略其他代码..
@ Override
public Response sendRequest ( Request request) {
if ( StringUtils . isBlank (appId) || StringUtils . isBlank (appToken)) {
throw new NoAuthorizationRuntimeException( ... ) ;
}
request . addPayload ( "app-id" , appId);
request . addPayload ( "app-token" , appToken);
return super . sendRequest (request);
}
} 如果传递进 demoFunction() 函数的是父类 Transporter 对象，那 demoFunction() 函数并不会有异常抛出，但如果传递给 demoFunction() 函数的是子类 SecurityTransporter 对象，那 demoFunction() 有可能会有异常抛出。这样子类替换父类传递进 demoFunction 函数之后，整个程序的逻辑行为有了改变 。
虽然从定义描述和代码实现上来看，多态和里式替换有点类似，但它们关注的角度是不一样的。
多态是面向对象编程的一大特性，也是面向对象编程语言的一种语法。它是一种代码实现的思路。
而里式替换是一种设计原则，是用来指导继承关系中子类该如何设计的，子类的设计要保证在替换父类的时候，不改变原有程序的逻辑以及不破坏原有程序的正确性。
3.2 哪些代码明显违背了 LSP？
子类在设计的时候，要遵守父类的行为约定（或者叫协议） 。父类定义了函数的行为约定，那子类可以改变函数的内部实现逻辑，但不能改变函数原有的行为约定 。这里的行为约定包括：
实际上，定义中父类和子类之间的关系，也可以替换成接口和实现类之间的关系。
3.2.1 子类违背父类声明要实现的功能
父类中提供的 sortOrdersByAmount() 订单排序函数，是按照金额从小到大来给订单排序的，而子类重写这个 sortOrdersByAmount() 订单排序函数之后，是按照创建日期来给订单排序的。那子类的设计就违背里式替换原则。
3.2.2 子类违背父类对输入、输出、异常的约定
在父类中，某个函数约定：运行出错的时候返回 null；获取数据为空的时候返回空集合（empty collection）。而子类重载函数之后，实现变了，运行出错返回异常（exception），获取不到数据返回 null。那子类的设计就违背里式替换原则。
在父类中，某个函数约定，输入数据可以是任意整数，但子类实现的时候，只允许输入数据是正整数，负数就抛出，也就是说，子类对输入的数据的校验比父类更加严格 ，那子类的设计就违背了里式替换原则。
在父类中，某个函数约定，只会抛出 ArgumentNullException 异常，那子类的设计实现中只允许抛出 ArgumentNullException 异常，任何其他异常的抛出，都会导致子类违背里式替换原则。
3.2.3 子类违背父类注释中所罗列的任何特殊说明
父类中定义的 withdraw() 提现函数的注释是这么写的：“用户的提现金额不得超过账户余额……”，而子类重写 withdraw() 函数之后，针对 VIP 账号实现了透支提现的功能，也就是提现金额可以大于账户余额，那这个子类的设计也是不符合里式替换原则的。
以上便是三种典型的违背里式替换原则的情况。除此之外，判断子类的设计实现是否违背里式替换原则，还有一个小窍门，那就是拿父类的单元测试去验证子类的代码 。如果某些单元测试运行失败，就有可能说明，子类的设计实现没有完全地遵守父类的约定，子类有可能违背了里式替换原则。
3.3 总结
理解里式替换原则，最核心的就是理解“design by contract，按照协议来设计”这几个字。也就是说那子类可以改变函数的内部实现逻辑，但不能改变函数原有的“约定”。
从开闭原则看里式替换，也就是子类只能扩展父类的实现，但是不能修改父类的实现。父类的逻辑和子类逻辑不能差别太多，违反了父类的约定。如果没有约定，抽象就困难起来，在任何时候都需要考虑所有子类的实现细节，多态也就没有意义。
违反里式替换的缺点：
反直觉 。期望所有子类行为是一致的，但如果不一致可能需要文档记录，或者在代码跑失败后涨此知识；
不可读 。如果子类行为不一致，可能需要不同的逻辑分支来适配不同的行为，徒增代码复杂度；
4. 接口隔离原则
4.1 如何理解“接口隔离原则”？
概念：客户端不应该被强迫依赖它不需要的接口 。
在这条原则中，我们可以把“接口”理解为下面三种东西：
4.2 把“接口”理解为一组 API 接口集合
微服务用户系统提供了一组跟用户相关的 API 给其他系统使用，比如：注册、登录、获取用户信息等。具体代码如下所示：
复制
public interface UserService {
boolean register ( String cellphone , String password);
boolean login ( String cellphone , String password);
UserInfo getUserInfoById ( long id);
UserInfo getUserInfoByCellphone ( String cellphone);
}
public class UserServiceImpl implements UserService {
//...
} 现在，我们的后台管理系统要实现删除用户的功能，希望用户系统提供一个删除用户的接口。
删除用户是一个非常慎重的操作，我们只希望通过后台管理系统来执行，所以这个接口只限于给后台管理系统使用。如果我们把它放到 UserService 中，那所有使用到 UserService 的系统，都可以调用这个接口。不加限制地被其他业务系统调用，就有可能导致误删用户。
我们参照接口隔离原则，调用者不应该强迫依赖它不需要的接口 ，将删除接口单独放到另外一个接口 RestrictedUserService 中，然后将 RestrictedUserService 只打包提供给后台管理系统来使用。具体的代码实现如下所示：
复制
public interface UserService {
boolean register ( String cellphone , String password);
boolean login ( String cellphone , String password);
UserInfo getUserInfoById ( long id);
UserInfo getUserInfoByCellphone ( String cellphone);
}
public interface RestrictedUserService {
boolean deleteUserByCellphone ( String cellphone);
boolean deleteUserById ( long id);
}
public class UserServiceImpl implements UserService , RestrictedUserService {
// ...省略实现代码...
} 在设计微服务或者类库接口的时候，如果部分接口只被部分调用者使用，那我们就需要将这部分接口隔离出来，单独给对应的调用者使用，而不是强迫其他调用者也依赖这部分不会被用到的接口。
4.3 把“接口”理解为单个 API 接口或函数
把接口理解为单个接口或函数。那接口隔离原则就可以理解为：函数的设计要功能单一，不要将多个不同的功能逻辑在一个函数中实现 。接下来，我们还是通过一个例子来解释一下。
复制
public class Statistics {
private Long max;
private Long min;
private Long average;
private Long sum;
private Long percentile99;
private Long percentile999;
//...省略constructor/getter/setter等方法...
}
public Statistics count( Collection< Long > dataSet) {
Statistics statistics = new Statistics() ;
//...省略计算逻辑...
return statistics;
} 在上面的代码中，count() 函数的功能不够单一，包含很多不同的统计功能，比如，求最大值、最小值、平均值等等。按照接口隔离原则，我们应该把 count() 函数拆成几个更小粒度的函数，每个函数负责一个独立的统计功能。拆分之后的代码如下所示：
复制
public Long max( Collection< Long > dataSet) { //... }
public Long min( Collection< Long > dataSet) { //... }
public Long average( Colletion< Long > dataSet) { //... }
// ...省略其他统计函数... 不过，你可能会说，在某种意义上讲，count() 函数也不能算是职责不够单一，毕竟它做的事情只跟统计相关。我们在讲单一职责原则的时候，也提到过类似的问题。实际上，判定功能是否单一，除了很强的主观性，还需要结合具体的场景 。
如果在项目中，对每个统计需求，Statistics 定义的那几个统计信息都有涉及，那 count() 函数的设计就是合理的。相反，如果每个统计需求只涉及 Statistics 罗列的统计信息中一部分，比如，有的只需要用到 max、min、average 这三类统计信息，有的只需要用到 average、sum。而 count() 函数每次都会把所有的统计信息计算一遍，就会做很多无用功，势必影响代码的性能，特别是在需要统计的数据量很大的时候。所以，在这个应用场景下，count() 函数的设计就有点不合理了，我们应该按照第二种设计思路，将其拆分成粒度更细的多个统计函数。
不过，你应该已经发现，接口隔离原则跟单一职责原则有点类似，不过稍微还是有点区别 。
而接口隔离原则相对于单一职责原则，一方面它更侧重于接口的设计，另一方面它的思考的角度不同。它提供了一种判断接口是否职责单一的标准：通过调用者如何使用接口来间接地判定 。如果调用者只使用部分接口或接口的部分功能，那接口的设计就不够职责单一。
4.4 把“接口”理解为 OOP 中的接口概念
我们还可以把“接口”理解为 OOP 中的接口概念，比如 Java 中的 interface。
我还是通过一个例子来给你解释。假设我们的项目中用到了三个外部系统：Redis、MySQL、Kafka。每个系统都对应一系列配置信息，比如地址、端口、访问超时时间等。为了在内存中存储这些配置信息，供项目中的其他模块来使用，我们分别设计实现了三个 Configuration 类：RedisConfig、MysqlConfig、KafkaConfig。具体的代码实现如下所示。
复制
public class RedisConfig {
private ConfigSource configSource; //配置中心（比如zookeeper）
private String address;
private int timeout;
private int maxTotal;
//省略其他配置: maxWaitMillis,maxIdle,minIdle...
public RedisConfig ( ConfigSource configSource) {
this . configSource = configSource;
}
public String getAddress () {
return this . address ;
}
//...省略其他get()、init()方法...
public void update () {
//从configSource加载配置到address/timeout/maxTotal...
}
}
public class KafkaConfig { //...省略... }
public class MysqlConfig { //...省略... } 现在，我们有一个新的功能需求，希望支持 Redis 和 Kafka 配置信息的热更新。但是，因为某些原因，我们并不希望对 MySQL 的配置信息进行热更新。
为了实现这样一个功能需求，我们设计实现了一个 ScheduledUpdater 类，以固定时间频率（periodInSeconds）来调用 RedisConfig、KafkaConfig 的 update() 方法更新配置信息。具体的代码实现如下所示：
复制
public interface Updater {
void update ();
}
public class RedisConfig implemets Updater {
//...省略其他属性和方法...
@ Override
public void update () { //... }
}
public class KafkaConfig implements Updater {
//...省略其他属性和方法...
@ Override
public void update () { //... }
}
public class MysqlConfig { //...省略其他属性和方法... }
public class ScheduledUpdater {
private final ScheduledExecutorService executor = Executors . newSingleThreadScheduledExecutor ();;
private long initialDelayInSeconds;
private long periodInSeconds;
private Updater updater;
public ScheduleUpdater ( Updater updater , long initialDelayInSeconds , long periodInSeconds) {
this . updater = updater;
this . initialDelayInSeconds = initialDelayInSeconds;
this . periodInSeconds = periodInSeconds;
}
public void run () {
executor . scheduleAtFixedRate ( new Runnable() {
@ Override
public void run () {
updater . update ();
}
} , this . initialDelayInSeconds , this . periodInSeconds , TimeUnit . SECONDS );
}
}
public class Application {
ConfigSource configSource = new ZookeeperConfigSource( /*省略参数*/ ) ;
public static final RedisConfig redisConfig = new RedisConfig(configSource) ;
public static final KafkaConfig kafkaConfig = new KakfaConfig(configSource) ;
public static final MySqlConfig mysqlConfig = new MysqlConfig(configSource) ;
public static void main ( String [] args) {
ScheduledUpdater redisConfigUpdater = new ScheduledUpdater(redisConfig , 300 , 300 ) ;
redisConfigUpdater . run ();
ScheduledUpdater kafkaConfigUpdater = new ScheduledUpdater(kafkaConfig , 60 , 60 ) ;
kafkaConfigUpdater . run ();
}
} 刚刚的热更新的需求我们已经搞定了。我们又有了一个新的监控功能需求。我们可以在项目中开发一个内嵌的 SimpleHttpServer，输出项目的配置信息到一个固定的 HTTP 地址。但是，出于某些原因，我们只想暴露 MySQL 和 Redis 的配置信息，不想暴露 Kafka 的配置信息。
为了实现这样一个功能，我们还需要对上面的代码做进一步改造。
复制
public interface Updater {
void update ();
}
public interface Viewer {
String outputInPlainText ();
Map < String , String > output ();
}
public class RedisConfig implemets Updater, Viewer {
//...省略其他属性和方法...
@ Override
public void update () { //... }
@ Override
public String outputInPlainText() { //... }
@ Override
public Map< String , String > output() { //...}
}
public class KafkaConfig implements Updater {
//...省略其他属性和方法...
@ Override
public void update () { //... }
}
public class MysqlConfig implements Viewer {
//...省略其他属性和方法...
@ Override
public String outputInPlainText () { //... }
@ Override
public Map< String , String > output() { //...}
}
public class SimpleHttpServer {
private String host;
private int port;
private Map < String , List < Viewer >> viewers = new HashMap <>();
public SimpleHttpServer ( String host , int port) { //...}
public void addViewers( String urlDirectory , Viewer viewer) {
if ( ! viewers . containsKey (urlDirectory)) {
viewers . put (urlDirectory , new ArrayList < Viewer >());
}
this . viewers . get (urlDirectory) . add (viewer);
}
public void run() { //... }
}
public class Application {
ConfigSource configSource = new ZookeeperConfigSource() ;
public static final RedisConfig redisConfig = new RedisConfig(configSource) ;
public static final KafkaConfig kafkaConfig = new KakfaConfig(configSource) ;
public static final MySqlConfig mysqlConfig = new MySqlConfig(configSource) ;
public static void main ( String [] args) {
ScheduledUpdater redisConfigUpdater =
new ScheduledUpdater(redisConfig , 300 , 300 ) ;
redisConfigUpdater . run ();
ScheduledUpdater kafkaConfigUpdater =
new ScheduledUpdater(kafkaConfig , 60 , 60 ) ;
redisConfigUpdater . run ();
SimpleHttpServer simpleHttpServer = new SimpleHttpServer(“ 127.0 . 0 . 1” , 2389 ) ;
simpleHttpServer . addViewer ( "/config" , redisConfig);
simpleHttpServer . addViewer ( "/config" , mysqlConfig);
simpleHttpServer . run ();
}
} 我们设计了两个功能非常单一的接口：Updater 和 Viewer。ScheduledUpdater 只依赖 Updater 这个跟热更新相关的接口，不需要被强迫去依赖不需要的 Viewer 接口，满足接口隔离原则。同理，SimpleHttpServer 只依赖跟查看信息相关的 Viewer 接口，不依赖不需要的 Updater 接口，也满足接口隔离原则。
这种设计思路灵活、易扩展、易复用 。因为 Updater、Viewer 职责更加单一，单一就意味了通用、复用性好。
4.5 总结
接口隔离原则首先要明白接口有哪几种，可能会是一组API接口集合，单个函数或者OOP中的接口。那么针对不同接口，解释也会不一样。
一组API接口集合：调用者不应该强迫依赖它不需要的接口，调用者可能不需要这些接口就不必再提供给调用者，只提供调用者需要的接口。
单个函数：单个函数需要职责单一，不要将多个功能放在一个函数中实现，可能调用者只需要部分功能，其他都是无用功。
OOP中的接口：接口的设计要尽量单一，不要让实现类依赖不需要的函数。
5. 依赖反转原则
来自：理论五：控制反转、依赖反转、依赖注入，这三者有何区别和联系？
5.1 控制反转（IOC）
控制反转的英文翻译是 Inversion Of Control，缩写为 IOC。
我们先通过一个例子来看一下，什么是控制反转。
复制
public class UserServiceTest {
public static boolean doTest () {
// ...
}
public static void main ( String [] args) { //这部分逻辑可以放到框架中
if ( doTest() ) {
System . out . println ( "Test succeed." );
} else {
System . out . println ( "Test failed." );
}
}
} 在上面的代码中，所有的流程都由程序员来控制。
如果我们抽象出一个下面这样一个框架，我们再来看，如何利用框架来实现同样的功能。
具体的代码实现如下所示：
复制
public abstract class TestCase {
public void run () {
if ( doTest() ) {
System . out . println ( "Test succeed." );
} else {
System . out . println ( "Test failed." );
}
}
public abstract boolean doTest ();
}
public class JunitApplication {
private static final List < TestCase > testCases = new ArrayList <>();
public static void register ( TestCase testCase) {
testCases . add (testCase);
}
public static final void main ( String [] args) {
for ( TestCase case : testCases) {
case . run ();
}
} 把这个简化版本的测试框架引入到工程中之后，我们只需要在框架预留的扩展点，也就是 TestCase 类中的 doTest() 抽象函数中，填充具体的测试代码就可以实现之前的功能了，完全不需要写负责执行流程的 main() 函数了。 具体的代码如下所示：
复制
public class UserServiceTest extends TestCase {
@ Override
public boolean doTest () {
// ...
}
}
// 注册操作还可以通过配置的方式来实现，不需要程序员显示调用register()
JunitApplication . register ( new UserServiceTest() ; 框架提供了一个可扩展的代码骨架，用来组装对象、管理整个执行流程 。程序员利用框架进行开发的时候，只需要往预留的扩展点上，添加跟自己业务相关的代码，就可以利用框架来驱动整个程序流程的执行。
这里的“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程可以通过框架来控制。流程的控制权从程序员“反转”到了框架 。
5.2 依赖注入（DI）
依赖注入跟控制反转恰恰相反，它是一种具体的编码技巧。依赖注入的英文翻译是 Dependency Injection，缩写为 DI。
那到底什么是依赖注入呢？我们用一句话来概括就是：不通过 new() 的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用 。
我们还是通过一个例子来解释一下。
在这个例子中，Notification 类负责消息推送，依赖 MessageSender 类实现推送商品促销、验证码等消息给用户。我们分别用依赖注入和非依赖注入两种方式来实现一下。
具体的实现代码如下所示：
复制
// 非依赖注入实现方式
public class Notification {
private MessageSender messageSender;
public Notification () {
this . messageSender = new MessageSender() ; //此处有点像hardcode
}
public void sendMessage ( String cellphone , String message) {
//...省略校验逻辑等...
this . messageSender . send (cellphone , message);
}
}
public class MessageSender {
public void send ( String cellphone , String message) {
//....
}
}
// 使用Notification
Notification notification = new Notification() ;
// 依赖注入的实现方式
public class Notification {
private MessageSender messageSender;
// 通过构造函数将messageSender传递进来
public Notification ( MessageSender messageSender) {
this . messageSender = messageSender;
}
public void sendMessage ( String cellphone , String message) {
//...省略校验逻辑等...
this . messageSender . send (cellphone , message);
}
}
//使用Notification
MessageSender messageSender = new MessageSender() ;
Notification notification = new Notification(messageSender) ; 通过依赖注入的方式来将依赖的类对象传递进来，这样就提高了代码的扩展性，我们可以灵活地替换依赖的类 。这一点在我们之前讲“开闭原则”的时候也提到过。
当然，上面代码还有继续优化的空间，我们还可以把 MessageSender 定义成接口，基于接口而非实现编程。
改造后的代码如下所示：
复制
public class Notification {
private MessageSender messageSender;
public Notification ( MessageSender messageSender) {
this . messageSender = messageSender;
}
public void sendMessage ( String cellphone , String message) {
this . messageSender . send (cellphone , message);
}
}
public interface MessageSender {
void send ( String cellphone , String message);
}
// 短信发送类
public class SmsSender implements MessageSender {
@ Override
public void send ( String cellphone , String message) {
//....
}
}
// 站内信发送类
public class InboxSender implements MessageSender {
@ Override
public void send ( String cellphone , String message) {
//....
}
}
//使用Notification
MessageSender messageSender = new SmsSender() ;
Notification notification = new Notification(messageSender) ; 尽管依赖注入非常简单，但却非常有用，在后面的章节中，我们会讲到，它是编写可测试性代码最有效的手段 。
5.3 依赖注入框架（DI Framework）
在采用依赖注入实现的 Notification 类中，虽然我们不需要用类似 hard code 的方式，在类内部通过 new 来创建 MessageSender 对象，但是，这个创建对象、组装（或注入）对象的工作仅仅是被移动到了更上层代码而已，还是需要我们程序员自己来实现。
具体代码如下所示：
复制
public class Demo {
public static final void main ( String args[]) {
MessageSender sender = new SmsSender() ; //创建对象
Notification notification = new Notification(sender) ; //依赖注入
notification . sendMessage ( "13918942177" , "短信验证码：2346" );
}
} 在实际的软件开发中，一些项目可能会涉及几十、上百、甚至几百个类，类对象的创建和依赖注入会变得非常复杂。如果这部分工作都是靠程序员自己写代码来完成，容易出错且开发成本也比较高。而对象创建和依赖注入的工作，本身跟具体的业务无关，我们完全可以抽象成框架来自动完成 。
这个框架就是“依赖注入框架 ”。我们只需要通过依赖注入框架提供的扩展点，简单配置一下所有需要创建的类对象、类与类之间的依赖关系，就可以实现由框架来自动创建对象、管理对象的生命周期、依赖注入等原本需要程序员来做的事情。
Spring 框架自己声称是控制反转容器（Inversion Of Control Container），而 Spring 框架的控制反转主要是通过依赖注入 来实现的。
5.4 依赖反转原则（DIP）
依赖反转原则的英文翻译是 Dependency Inversion Principle，缩写为 DIP。中文翻译有时候也叫依赖倒置原则。
大概意思就是：高层模块（high-level modules）不要依赖低层模块（low-level）。高层模块和低层模块应该通过抽象（abstractions）来互相依赖。除此之外，抽象（abstractions）不要依赖具体实现细节（details），具体实现细节（details）依赖抽象（abstractions） 。
所谓高层模块和低层模块的划分，简单来说就是，在调用链上，调用者属于高层，被调用者属于低层 。低层比高层更加稳定，一般不会轻易修改低层模块的代码。
我们拿 Tomcat 这个 Servlet 容器作为例子来解释一下。
Tomcat 是运行 Java Web 应用程序的容器。我们编写的 Web 应用程序代码只需要部署在 Tomcat 容器下，便可以被 Tomcat 容器调用执行。
按照之前的划分原则，Tomcat 就是高层模块，我们编写的 Web 应用程序代码就是低层模块。Tomcat 和应用程序代码之间并没有直接的依赖关系，两者都依赖同一个“抽象”，也就是 Servlet 规范 。Servlet 规范不依赖具体的 Tomcat 容器和应用程序的实现细节，而 Tomcat 容器和应用程序依赖 Servlet 规范。
5.5 总结
首先明白控制反转，依赖注入以及依赖注入框架的区别。
控制反转：“控制”指的是对程序执行流程的控制，而“反转”指的是在没有使用框架之前，程序员自己控制整个程序的执行。在使用框架之后，整个程序的执行流程可以通过框架来控制。流程的控制权从程序员“反转”到了框架 。
依赖注入：不通过 new() 的方式在类内部创建依赖类对象，而是将依赖的类对象在外部创建好之后，通过构造函数、函数参数等方式传递（或注入）给类使用
依赖注入框架：对象的创建和注入本身和业务是无关的，所以需要依赖注入框架帮我们来自动创建对象，实现依赖注入，管理对象的生命周期。
其次就是理解依赖反转原则，高层模块和低层模块的区别，为什么高层模块和低层模块应该通过抽象来互相依赖，抽象不能依赖实现，实现依赖抽象。
6. 迪米特法则
来自：理论八：如何用迪米特法则（LOD）实现“高内聚、松耦合”？
6.1 何为“高内聚、松耦合”？
“高内聚、松耦合”是一个非常重要的设计思想，能够有效地提高代码的可读性和可维护性，缩小功能改动导致的代码改动范围 。
实际上，“高内聚、松耦合”是一个比较通用的设计思想，可以用来指导不同粒度代码的设计与开发，比如系统、模块、类，甚至是函数，也可以应用到不同的开发场景中，比如微服务、框架、组件、类库等。
在这个设计思想中，“高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间依赖关系的设计。
6.1.1 什么是“高内聚”呢？
所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。相近的功能往往会被同时修改，放到同一个类中，修改会比较集中，代码容易维护。
6.1.2 什么又是“松耦合”？
所谓松耦合是说，在代码中，类与类之间的依赖关系简单清晰 。即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动 。
6.1.3 “内聚”和“耦合”之间的关系
高内聚”有助于“松耦合”，同理，“低内聚”也会导致“紧耦合”。
关于这一点，我画了一张对比图来解释。图中左边部分的代码结构是“高内聚、松耦合”；右边部分正好相反，是“低内聚、紧耦合”。
图中左边部分的代码设计中，类的粒度比较小，每个类的职责都比较单一。相近的功能都放到了一个类中，不相近的功能被分割到了多个类中。这样类更加独立，代码的内聚性更好。因为职责单一，所以每个类被依赖的类就会比较少，代码低耦合。一个类的修改，只会影响到一个依赖类的代码改动。我们只需要测试这一个依赖类是否还能正常工作就行了。
图中右边部分的代码设计中，类粒度比较大，低内聚，功能大而全，不相近的功能放到了一个类中。这就导致很多其他类都依赖这个类。当我们修改这个类的某一个功能代码的时候，会影响依赖它的多个类。我们需要测试这三个依赖类，是否还能正常工作。
除此之外，从图中我们也可以看出，高内聚、低耦合的代码结构更加简单、清晰，相应地，在可维护性和可读性上确实要好很多 。
6.2 “迪米特法则”理论描述
概念：每个模块（unit）只应该了解那些与它关系密切的模块（units: only units “closely” related to the current unit）的有限知识（knowledge）。或者说，每个模块只和自己的朋友“说话”（talk），不和陌生人“说话”（talk） 。
也就是：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口 （也就是定义中的“有限知识”）
6.3 理论解读与代码实战一
我们先来看这条原则中的前半部分，“不该有直接依赖关系的类之间，不要有依赖 ”。
我举个例子解释一下。
这个例子实现了简化版的搜索引擎爬取网页的功能。代码中包含三个主要的类。其中，NetworkTransporter 类负责底层网络通信，根据请求获取数据；HtmlDownloader 类用来通过 URL 获取网页；Document 表示网页文档，后续的网页内容抽取、分词、索引都是以此为处理对象。
具体的代码实现如下所示：
复制
public class NetworkTransporter {
// 省略属性和其他方法...
public Byte [] send ( HtmlRequest htmlRequest) {
//...
}
}
public class HtmlDownloader {
private NetworkTransporter transporter; //通过构造函数或IOC注入
public Html downloadHtml ( String url) {
Byte [] rawHtml = transporter . send ( new HtmlRequest(url) );
return new Html(rawHtml) ;
}
}
public class Document {
private Html html;
private String url;
public Document ( String url) {
this . url = url;
HtmlDownloader downloader = new HtmlDownloader() ;
this . html = downloader . downloadHtml (url);
}
//...
} 首先，我们来看 NetworkTransporter 类。作为一个底层网络通信类，我们希望它的功能尽可能通用，而不只是服务于下载 HTML，所以，我们不应该直接依赖太具体的发送对象 HtmlRequest。从这一点上讲，NetworkTransporter 类的设计违背迪米特法则，依赖了不该有直接依赖关系的 HtmlRequest 类。
我们应该如何进行重构，让 NetworkTransporter 类满足迪米特法则呢？
我这里有个形象的比喻。假如你现在要去商店买东西，你肯定不会直接把钱包给收银员，让收银员自己从里面拿钱，而是你从钱包里把钱拿出来交给收银员 。
这里的 HtmlRequest 对象就相当于钱包，HtmlRequest 里的 address 和 content 对象就相当于钱。我们应该把 address 和 content 交给 NetworkTransporter，而非是直接把 HtmlRequest 交给 NetworkTransporter。这里也能把address和content包装成一个类。
复制
public class NetworkTransporter {
// 省略属性和其他方法...
public Byte [] send ( String address , Byte [] data) {
//...
}
} 我们再来看 HtmlDownloader 类。这个类的设计没有问题。
不过，我们修改了 NetworkTransporter 的 send() 函数的定义，而这个类用到了 send() 函数，所以我们需要对它做相应的修改，修改后的代码如下所示：
复制
public class HtmlDownloader {
private NetworkTransporter transporter; //通过构造函数或IOC注入
// HtmlDownloader这里也要有相应的修改
public Html downloadHtml ( String url) {
HtmlRequest htmlRequest = new HtmlRequest(url) ;
Byte [] rawHtml = transporter . send (
htmlRequest . getAddress () , htmlRequest . getContent () . getBytes ());
return new Html(rawHtml) ;
}
} 最后，我们来看下 Document 类。这个类的问题比较多，主要有三点。
第一，构造函数中的 downloader.downloadHtml() 逻辑复杂，耗时长，不应该放到构造函数中，会影响代码的可测试性。代码的可测试性我们后面会讲到，这里你先知道有这回事就可以了。
第二，HtmlDownloader 对象在构造函数中通过 new 来创建，违反了基于接口而非实现编程的设计思想，也会影响到代码的可测试性。
第三，从业务含义上来讲，Document 网页文档没必要依赖 HtmlDownloader 类，违背了迪米特法则。
修改之后的代码如下所示：
复制
public class Document {
private Html html;
private String url;
public Document ( String url , Html html) {
this . html = html;
this . url = url;
}
//...
}
// 通过一个工厂方法来创建Document
public class DocumentFactory {
private HtmlDownloader downloader;
public DocumentFactory ( HtmlDownloader downloader) {
this . downloader = downloader;
}
public Document createDocument ( String url) {
Html html = downloader . downloadHtml (url);
return new Document(url , html) ;
}
} 6.4 理论解读与代码实战二
现在，我们再来看一下这条原则中的后半部分：“有依赖关系的类之间，尽量只依赖必要的接口 ”。
下面这段代码非常简单，Serialization 类负责对象的序列化和反序列化。
复制
public class Serialization {
public String serialize ( Object object) {
String serializedResult = ... ;
//...
return serializedResult;
}
public Object deserialize ( String str) {
Object deserializedResult = ... ;
//...
return deserializedResult;
}
} 单看这个类的设计，没有一点问题。不过，如果我们把它放到一定的应用场景里，那就还有继续优化的空间。假设在我们的项目中，有些类只用到了序列化操作，而另一些类只用到反序列化操作。那基于迪米特法则后半部分“有依赖关系的类之间，尽量只依赖必要的接口”，只用到序列化操作的那部分类不应该依赖反序列化接口。同理，只用到反序列化操作的那部分类不应该依赖序列化接口 。
根据这个思路，我们应该将 Serialization 类拆分为两个更小粒度的类，一个只负责序列化（Serializer 类），一个只负责反序列化（Deserializer 类）。拆分之后，使用序列化操作的类只需要依赖 Serializer 类，使用反序列化操作的类只需要依赖 Deserializer 类。拆分之后的代码如下所示：
复制
public class Serializer {
public String serialize ( Object object) {
String serializedResult = ... ;
...
return serializedResult;
}
}
public class Deserializer {
public Object deserialize ( String str) {
Object deserializedResult = ... ;
...
return deserializedResult;
}
} 尽管拆分之后的代码更能满足迪米特法则，但却违背了高内聚的设计思想 。
高内聚要求相近的功能要放到同一个类中，这样可以方便功能修改的时候，修改的地方不至于过于分散。对于刚刚这个例子来说，如果我们修改了序列化的实现方式，比如从 JSON 换成了 XML，那反序列化的实现逻辑也需要一并修改。在未拆分的情况下，我们只需要修改一个类即可。在拆分之后，我们需要修改两个类。显然，这种设计思路的代码改动范围变大了。
如果我们既不想违背高内聚的设计思想，也不想违背迪米特法则，那我们该如何解决这个问题呢？
实际上，通过引入两个接口就能轻松解决这个问题，具体的代码如下所示。
复制
public interface Serializable {
String serialize ( Object object);
}
public interface Deserializable {
Object deserialize ( String text);
}
public class Serialization implements Serializable , Deserializable {
@ Override
public String serialize ( Object object) {
String serializedResult = ... ;
...
return serializedResult;
}
@ Override
public Object deserialize ( String str) {
Object deserializedResult = ... ;
...
return deserializedResult;
}
}
public class DemoClass_1 {
private Serializable serializer;
public Demo ( Serializable serializer) {
this . serializer = serializer;
}
//...
}
public class DemoClass_2 {
private Deserializable deserializer;
public Demo ( Deserializable deserializer) {
this . deserializer = deserializer;
}
//...
} 尽管我们还是要往 DemoClass_1 的构造函数中，传入包含序列化和反序列化的 Serialization 实现类，但是，我们依赖的 Serializable 接口只包含序列化操作，DemoClass_1 无法使用 Serialization 类中的反序列化接口，对反序列化操作无感知，这也就符合了迪米特法则后半部分所说的“依赖有限接口”的要求。
实际上，上面的的代码实现思路也体现了“基于接口而非实现编程 ”的设计原则，结合迪米特法则，我们可以总结出一条新的设计原则，那就是“基于最小接口而非最大实现编程 ”。
6.5 辩证思考与灵活应用
设计原则本身没有对错，只有能否用对之说。不要为了应用设计原则而应用设计原则，我们在应用设计原则的时候，一定要具体问题具体分析。
对于刚刚这个 Serialization 类来说，只包含两个操作，确实没有太大必要拆分成两个接口。但是，如果我们对 Serialization 类添加更多的功能，实现更多更好用的序列化、反序列化函数，我们来重新考虑一下这个问题。修改之后的具体的代码如下：
复制
public class Serializer { // 参看JSON的接口定义
public String serialize ( Object object) { //... }
public String serializeMap( Map map) { //... }
public String serializeList( List list) { //... }
public Object deserialize( String objectString) { //... }
public Map deserializeMap( String mapString) { //... }
public List deserializeList( String listString) { //... }
} 在这种场景下，第二种设计思路要更好些。因为基于之前的应用场景来说，大部分代码只需要用到序列化的功能。对于这部分使用者，没必要了解反序列化的“知识”，而修改之后的 Serialization 类，反序列化的“知识”，从一个函数变成了三个。一旦任一反序列化操作有代码改动，我们都需要检查、测试所有依赖 Serialization 类的代码是否还能正常工作。为了减少耦合和测试工作量，我们应该按照迪米特法则，将反序列化和序列化的功能隔离开来。
6.6 总结
首先要理解什么是高内聚，低耦合。
高内聚：相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。
低耦合：在代码中，类与类之间的依赖关系简单清晰，一个类的改动不会影响另外的类。
其次就是理解迪米特法则：不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口 。
