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

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的代码能否还能正常工作。而其实部分使用者并没必要理解反序列化的“知识”，它们仅用到序列化。那么我们应该按照迪米特法则，将反序列化和序列化的功能隔离开来。