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