欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

读《Unix编程艺术》 第四章:模块化、保持清晰、保持简洁 博客分类: 随笔 编程Unix数据结构工作 

程序员文章站 2024-02-03 13:50:40
...

第四章: 模块化、保持清晰、保持简洁.

软件设计有两种方式 : 一种是设计得极为简洁,没有看得到的缺陷;另外一种是设计得极为复杂,有缺陷也看不出来,显然,第一种方式的难度要大得多。

模块化的原则:  要编写复杂的软件又不至于一败涂地地唯一方法,就是用定义清晰的接口把若干简单模块组合起来,如此一来,多数问题只会出现在局部,那么还有希望对局部进行改进和优化,而不至于牵动全身.

相对于其他,Unix程序员更加重视模块化、更注重正交性和紧凑性等问题。

封装和最佳模块化大小
  模块化的首要特质是封装。
------- 封装良好的模块不会过多向外部披露自身的细节,不会直接调用其他模块的实现代码,也不会胡乱共享全局数据.

  模块之间通过API和数据结构进行通信.

检测一组API是否设计良好,你可以:
尝试用人类自然语言来描述,是否可以把事情说清楚?

模块分得越彻底,就意味着每一块就越小;
当然,模块化代码也不可过于小;
   模块过小时,几乎所有复杂度都在接口;想要理解任何一段代码前,必须理解全部代码,因此阅读代码非常困难
     Hatton的经验数据表明,200~400之间逻辑行代码是模块设计的"最佳点"

紧凑性和正交性
  紧凑性就是一个设计是否能进入人脑中特性。
   检验一个设计是否紧凑的方法是: 有经验的用户通过需要操作手册吗? 如果不需要,则设计就是紧凑的。
  紧凑的工具和顺手的自然工具一样: 让人乐于使用,不会在你的想法和工作之间格格不入。

  正交性是有助于使复杂设计也能紧凑的重要特性之一。 既: 每一个动作只改变一件事,不会影响其他。无论是什么系统,改变每个属性的方法只有一个 。
   比如显示器,改变亮度而不会影响对比度。

 
模块式编码

  模块式,模块式,那么改如何做?
  编写代码之前,问问自己以下问题:
  1.有多少全局变量? 全局变量对于模块化是毒药,很容易使各模块化轻率、胡乱地相互泄漏信息。
  2.单个模块大小是否在Hatton的最佳范围之内?  如果不是,超过就可能产生长期的维护问题。
  3.模块内的单个函数是否太大了? 这不是一个行数计算问题,而是一个复杂性问题。 如果不能以一句话来简单描述一个函数与其调用程序之间的约定,这个函数可能太大拉。
  4.代码是否有内部API---好的API应是意义清楚,不用看具体如何实现就可理解的,不确定? 那么你打电话给另外一个程序员描述,如果说不清楚,那么API就可能过于复杂了.
   5.API的入口是不是超过7个?有没有哪个类超过7个方法,数据结构的成员是不是超过7个?
   6.整个项目中每个模块的入口点数量如何分布?是不是均匀?很多入口点的模块真的需要这么多入口点吗? 记住: 模块复杂性往往和入口点数量的平方成正比----这也是简单API优于复杂API的另一个原因.