Coding Style Guide 之软件设计原则初探

软件设计原则

• 面向接口编程，而不是面向实现。接口是稳定的，而实现是多样的。
• 命令-查询分离原则：
  当一个方法返回一个值来回应一个问题的时候，它就具有查询的性质；当一个方法要改变对象的状态的时候，它就具有命令的性质。查询不会改变对象的状态，命令会改变对象的状态，因此查询操作是安全的、性能好的。
  举例：读写分离。
• You Ain’t Gonna Need It：意思是不要过度设计。过度设计会提高复杂程度，有些设计可能在整个软件的生命周期中都不会用到，过度设计严重可能会导致项目的失败。不要提前实现不需要的功能，等需要的时候再添加。

• Law of Demeter &　Principle of Least Knowledge：只知道自己需要知道的东西。

  对于对象 ‘O’ 中一个方法’M’，M应该只能够访问以下对象中的方法：

  • 对象O；
  • 与O直接相关的Component Object；
  • 由方法M创建或者实例化的对象；
  • 作为方法M的参数的对象。

  反例：

  final String outputDir = ctxt.getOptions().getScratchDir().getAbsolutePath();
  

• Common Closure Principle（CCP）– 共同封闭原则：一个包中所有的类应该对同一种类型的变化关闭。通俗的说：一个变化应当只影响一个包中的代码，而不是很多个包。
  举例：升级了某个依赖的jar包，一般情况下并不需要改变自己的代码。

• Common Reuse Principle (CRP) – 共同重用原则：包的所有类被一起重用。如果你重用了其中的一个类，就重用全部。换个说法是，没有被一起重用的类不应该被组合在一起。该原则确定哪些类应当放到同一个包里，同时要求包的使用者在包改变升级时必须进行回归测试。

• Hollywood Principle – 好莱坞原则：组件初始化和调用都由容器负责。组件处在一个容器当中，由容器负责管理。是IOC/DI的基础原则。

• Convention over Configuration（CoC）– 惯例优于配置原则。将一些公认的配置方式和信息作为内部缺省的规则来使用。
  举例：MyBatis：如果数据库中表的列名与Entity的属性名一致，则不需要再声明ResultMap。

• Separation of Concerns (SoC) – 关注点分离：将问题的关注点分开，分为许多独立小问题，便于解决。说白了还是“高内聚，低耦合”。

• Design by Contract (DbC) – 契约式设计。
  对于类的一个方法，都有一个前提条件以及一个后续条件，前提条件说明方法接受什么样的参数数据等，只有前提条件得到满足时，这个方法才能被调用；同时后续条件用来说明这个方法完成时的状态，如果一个方法的执行会导致这个方法的后续条件不成立，那么这个方法也不应该正常返回。应用到子类中即继承类方法的行为和输出不得违反由基类建立起来的任何约束，不能让用户对继承类方法的输出感到困惑。

• Acyclic Dependencies Principle (ADP) – 无环依赖原则。包之间的不允许循环依赖，耦合程度太高。如何解耦：1.抽出共同部分，打破循环依赖；2.使用DIP（依赖倒置原则）和ISP（接口分隔原则）。