写给你们看的设计书——读后笔记

     《写给你们看的设计书》介绍了设计的四个基本原则：亲密性、对齐、重复、对比。做为一个软件“设计师”，我也来聊聊读过这本书以后，我对这四个原则的一点理解。

亲密性

        亲密性原则是指：内涵相关联的内容，在结构、关系上也应保持关联。
        以软件设计的角度来讲，一项业务所包含的功能、一个功能所包含的代码，应该在结构、关系上保持关联。例如把这些代码放到同一个包下、用同一套规则来命名。这样，当咱们须要查阅、修改这个功能，须要处理哪些代码就“一望而知”了。
        很明显，“亲密性”实际上就是软件工程中常说的“高内聚”。“高内聚”之于软件工程，就如空气之于人同样：重要，却经常被忽视。最多见的一种忽视“高内聚”原则而产生的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也是一样的考虑。

对比

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

后记

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