亲密性

        亲密性原则是指：内涵相关联的内容，在结构、关系上也应保持关联。
        以软件设计的角度来说，一项业务所包含的功能、一个功能所包含的代码，应该在结构、关系上保持关联。例如把这些代码放到同一个包下、用同一套规则来命名。这样，当我们需要查阅、修改这个功能，需要处理哪些代码就“一望而知”了。
        很明显，“亲密性”实际上就是软件工程中常说的“高内聚”。“高内聚”之于软件工程，就如空气之于人一样：重要，却常常被忽视。最常见的一种忽视“高内聚”原则而产生的bad smell，就是不通过继承或组合的方式来新增业务逻辑，而是在原有代码中用if-else/switch-case等方式来扩展。这样一来，新功能的代码就无法放到新功能的“群组”内，进而，在查阅、修改新功能的代码时，无法“一望而知”工作范围、也无法“一望而知”风险范围。
        当然，上面的bad smell也可以说是违反了“低耦合”原则导致的。但是必须承认，违反了“高内聚”，则一定会违反“低耦合”。例如，操作Ecxel文件的Service类，却把POI组件泄露到接口之外——这是Excel操作代码不够内聚的缘故；这同时也导致了调用方与POI组件发生耦合，从而违反“低耦合”原则。
        “低耦合”可以称为“私密性”原则，不过《写给大家看的设计书》中没有相关论述。这大概是因为，其它领域内的设计是为了充分表达自己的设计目标——要“一望而知”。而软件设计不仅要“一望而知”，还要“一望仅知”。只有这样，才能充分地拆分和管理复杂度。

对齐

        “一望而知”各组件的内涵及范围，是“亲密性”原则的优点；而“一望而知”各组件之间的结构、关系，这是“对齐”原则带来的好处。标题对齐，“一望而知”全篇有几个标题；段落对齐，“一望而知”这个标题下有多少个段落。软件设计中会有这样的好事吗？
        我有一个很切身的体会，也是一个很好的例子：文件后缀命名。例如，某个接口类命名为AlphaService，那么它的所有子类都在接口名后面缀上说明性单词，以此构成自己的名字。如命名为AlphaServiceAsChain、AlphaServiceAsDispatcher、AlphaService4English、AlphaService4Chinense，诸如此类。这样，由于IDE和操作系统的文件系统、查询功能默认都是字母顺序排列，因而这一系列类在“展示”上就非常紧凑——这就使得它们的关系“一望而知”。
        “对齐”规则对现在的软件设计有很大的借鉴意义；规则如果执行得好，软件设计将会获益匪浅。这是因为，现代软件内部的逻辑复杂度一般都非常高。我们要通过设计来降低复杂度，一般只有一种办法：代码功能简单，而关系复杂。上面例子中提到的“接口-实现类”就是一种代码关系，而这种关系可以“一望而知”，这就是“对齐”原则给系统的裨益。
        当然，软件中“对齐”的方式还有很多。略牵强一点来讲，同一个接口下的实现类都是向接口“对齐”；同一个模板类下的子类都是向模板“对齐”；符合里氏替换原则的都算“对齐”；等等。

重复

        “重复”对其它领域的设计工作来说，也许确实是非常重要的一项原则。运用这项原则，可以把设计意图更加有效地表达出来。
        但是，重复无疑是我们软件开发和设计人员最痛恨的：Don't Repeat Yourself! DON'T!!
        也许这是软件设计与其它领域设计的一个不同之处。软件设计不仅要考虑表达设计意图，还要管理系统复杂度。“一望仅知”是一种方式，DRY也是同样的考虑。

对比

      设计中进行“对比”，一般是为了突出核心设计目的。对软件设计来说，“对比”原则参考意义不大。

后记

      最近的技术思考和积累，关注点都不在代码或系统的细节上，而是转向了一些业务系统或逻辑的设计上。这跟我的技术价值观有关：技术的价值是需要体现在业务系统中的。不过这可以另外展开，这里打住。
      “设计”行业由来已久，建筑设计、时装设计、包装设计、城市规划设计、工业设计、平面设计……等等等等。这些设计门类都已经积累了很多经验，软件设计能否从中汲取一些营养呢？这也是我开始涉猎《写给大家看的设计书》的原因。
      这本书偏“平面”设计——海报、广告、传单等。其设计目标与软件设计有些出入，因此，亲密性、对齐、重复和对比这四个原则，有些确实值得借鉴，有些只能说看看就好。

本文转自 斯然在天边 51CTO博客，原文链接：http://blog.51cto.com/winters1224/1967240，如需转载请自行联系原作者