设计原则与思想：设计原则

15 | 理论一：对于单一职责原则，如何判定某个类的职责是否够“单一”？

如何理解单一职责原则（SRP）？
那就是：一个类或者模块只负责完成一个职责（或者功能）。

如何判断类的职责是否足够单一？
我们可以先写一个粗粒度的类，满足业务需求。随着业务的发展，如果粗粒度的类越来越庞大，代码越来越多，这个时候，我们就可以将这个粗粒度的类，拆分成几个更细粒度的类。这就是所谓的持续重构
类的职责是否设计得越单一越好？

16 | 理论二：如何做到“对扩展开放、修改关闭”？扩展和修改各指什么？

大部分设计模式都是为了解决代码的扩展性问题而存在的，主要遵从的设计原则就是开闭原则
如何理解“对扩展开放、修改关闭”？

为了让你更好地理解这个原则，

1. 我举一个例子来进一步解释一下。这是一段 API 接口监控告警的代码。
   其中，AlertRule 存储告警规则，可以自由设置。Notification 是告警通知类，支持邮件、短信、微信、手机等多种通知渠道。NotificationEmergencyLevel 表示通知的紧急程度，包括 SEVERE（严重）、URGENCY（紧急）、NORMAL（普通）、TRIVIAL（无关紧要），不同的紧急程度对应不同的发送渠道。
   通知告警有多种方式，紧急程度也有多种情况，同时告警规则也是多种情况的(自定义)，这种方式考虑哪种设计模式呢？

2. 比如，我们代码中通过 Kafka 来发送异步消息。对于这样一个功能的开发，我们要学会将其抽象成一组跟具体消息队列（Kafka）无关的异步消息接口

MessageQueue
MessageFromatter
Notification
写出支持“对扩展开放、对修改关闭”的代码的关键是预留扩展点

1 如何理解“对扩展开放、对修改关闭”？
2.如何做到“对扩展开放、修改关闭”？

17 | 理论三：里式替换（LSP）跟多态有何区别？哪些代码违背了LSP？

子类对象（object of subtype/derived class）能够替换程序（program）中父类对象（object of base/parent class）出现的任何地方，并且保证原来程序的逻辑行为（behavior）不变及正确性不被破坏。
----可以理解为继承

18 | 理论四：接口隔离原则有哪三种应用？原则中的“接口”该如何理解？

• 一组 API 接口集合
• 单个 API 接口或函数
• OOP 中的接口概念

把“接口”理解为一组 API 接口集合
UserService RestrictedUserService
把“接口”理解为单个 API 接口或函数
把“接口”理解为 OOP 中的接口概念
假设我们的项目中用到了三个外部系统：Redis、MySQL、Kafka。每个系统都对应一系列配置信息，比如地址、端口、访问超时时间等。为了在内存中存储这些配置信息，供项目中的其他模块来使用，我们分别设计实现了三个 Configuration 类：RedisConfig、MysqlConfig、KafkaConfig。具体的代码实现如下所示。注意，这里我只给出了 RedisConfig 的代码实现，另外两个都是类似的，我这里就不贴了。

现在，我们有一个新的功能需求，希望支持 Redis 和 Kafka 配置信息的热更新

我们设计了两个功能非常单一的接口：Updater 和 Viewer

19 | 理论五：控制反转、依赖反转、依赖注入，这三者有何区别和联系？

20 | 理论六：我为何说KISS、YAGNI原则看似简单，却经常被用错？

代码行数越少就越“简单”吗？
代码逻辑复杂就违背 KISS 原则吗？
如何写出满足 KISS 原则的代码？
YAGNI 跟 KISS 说的是一回事吗？

21 | 理论七：重复的代码就一定违背DRY吗？如何提高代码的复用性？

22 | 理论八：如何用迪米特法则（LOD）实现“高内聚、松耦合”？

何为“高内聚、松耦合”？
“高内聚”用来指导类本身的设计，“松耦合”用来指导类与类之间依赖关系的设计。

所谓高内聚，就是指相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。

可以参看：2.设计模式七大原则