写给大家看的设计书——读后笔记

简介:

亲密性

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

相关文章
|
6月前
|
算法 芯片
嵌入式工程师如何快速的阅读datasheet的方法
嵌入式工程师如何快速的阅读datasheet的方法
146 0
|
Unix 程序员 编译器
编程修养(精品文,建议认真品读并实践)
编程修养(精品文,建议认真品读并实践)
47 0
|
程序员 前端开发
关于程序员写好 ppt 的几点总结
程序员日常工作中最多的应该是接收需求、编码实现需求。但也有些时候需要做一些非代码的文字工作。
142 0
关于程序员写好 ppt 的几点总结
快速背诵的心得体会
快速背诵的心得体会
126 0
快速背诵的心得体会
|
算法 程序员
|
UED
写给那些傻傻想做服务器开发的朋友
这篇博客原作者的博客链接:https://blog.csdn.net/analogous_love   写在前面的话 我在七八年前就看过这篇文章,那个时候我还是一名学生,它深深地影响了我学生时代以及后来的人生轨迹。
1255 0
阅读札记
我在 GitHub 上创建了一个关于 Reading 的 repo, 里面可以分享一些关于论文的阅读经验或者是一些精彩论文介绍亦或是精品博客之类的. 欢迎大家在此仓库提交一些新的, 优秀的资源! Github 地址是: https://q735613050.
1298 0
|
敏捷开发 程序员
书评 – 程序员经典读物(1)
早几天,笼统地就经典感慨了一番,接着来个逐一点评,算是有始有终了。经典是用来阅读而非膜拜的道理,自然是明白的,虽然我是属于比较推崇经典那一类的。阅读大致就是一个和作者交流的过程,有兴致时无妨感慨点评一番,算是对作者的一种致敬吧。
1231 0