《设计模式之美》笔记：设计原则

SOLD原则

KISS原则 - 尽量保持简单。

• 不要使用同事可能不懂的技术来实现代码。
• 不要重复造轮子，要善于使用已经有的工具类库。
• 不要过度优化。不要过度使用一些奇淫技巧（比如，位运算代替算术运算、复杂的条件语句代替if-else、使用一些过于底层的函数等）来优化代码，牺牲代码的可读性。

YAGNI原则 - You Ain't Gonna Need it.

• 不要去设计当前用不到的功能；不要去编写当前用不到的代码。核心思想就是：不要过度设计。
• 比如，如果暂时只用Redis存储配置信息，以后可能会用到ZooKeeper。那么在未用到ZooKeeper之前，我们没必要提前编写这部分代码。但是，这并不是说我们不需要考虑代码的扩展性。我们还是要预留好扩展点，等到需要的时候，再去实现ZooKeeper存储配置信息这部分代码。

DRY原则 - Don't Repeat Yourself.

• 区分三种典型代发重复情况：实现逻辑重复，功能语义重复，代码执行重复。
• 有时，尽管代码的实现逻辑相同，但语义不同，那么它并不违反DRY原则。对于重复代码的问题，可以通过抽象成更细粒度函数的方式解决。（isValidUserName()跟isValidPassword()的例子）
• 功能语义重复的情况，通常都违反了DRY原则。（isValidIp()跟checkIfIpValid()的例子）
• 代码执行重复，也通常是违反DRY原则的，应该尽量优化。
• 延伸：如何提高代码的复用性？
  • 减少代码耦合
  • 满足单一职责原则
  • 模块化
  • 业务与非业务逻辑分离
  • 通用代码下沉
  • 继承、多态、抽象、封装
  • 应用模板等设计模式
• 辩证：实际上，除非有非常明确的复用需求，否则为了暂时用不到的复用需求，花费太多的时间、精力，投入太多的开发成本，并不是一个值得推荐的做法。也违反了YAGNI原则。

LOD原则（迪米特法则） - 不该有直接依赖关系的类之间，不要有依赖；有依赖关系的类之间，尽量只依赖必要的接口。

• 高内聚：以类举例，相近的功能应该放到同一个类中，不相近的功能不要放到同一个类中。
• 松耦合：以类举例，类与类之间的依赖关系简单清晰。即使两个类有依赖关系，一个类的代码改动不会或者很少导致依赖类的代码改动。
• 辩证：设计原则本身没有对错，只有能否用对之说。不要为了应用设计原则而应用设计原则，我们在应用设计原则的时候，一定要具体问题具体分析。
  • 例子：序列化和反序列化是否应该分拆成两个接口？答案是看情况。
    • 如果Serialization类，只包含两个操作，没有太大必要分拆，否则就违背了高内聚思想。但如果Serialization类添加了更多功能，比如反序列化的函数变成了三个，一旦任一反序列化操作有代码改动，我们都需要检查测试所有依赖Serialization的代码是否还能正常工作。而其实部分使用者并没必要了解反序列化的“知识”，它们仅用到序列化。那么我们应该按照迪米特法则，将反序列化和序列化的功能隔离开来。