软件设计的粒度

软件设计的粒度

   说起粒度，最先进入我脑海的就是一杯沙子和一杯石头。粒度也是我进入公司后听到最有分量的一个词，因为那时导师告诉我这很重要，但很难言传，需要自己去领悟才能把握。做设计要注意粒度，写代码也要注意粒度。对于同一个问题的分解，每个人都会根据不同的动机有不同的分解方法和分解粒度。那么怎么去把握粒度呢？

 

   关于这个问题，让我们先看看一个生活中的例子。同样一个任务，有的人可能预计3步就能完成，有的人需要5步，还有的人需要10步。具体实现起来，预计3步完成的可能在某一步会手忙脚乱的，因为计划过于粗泛；而预计10步的虽然可以按部就班，但可能效率会有所影响。总的来说，粒度的划分可能不会影响任务的最终完成，可往往会对完成的过程造成影响。是3步还是10步，每个人可能都有一个自己的考虑和角度，但通过不断实践和总结还是可以在相互之间找到一个比较合理的范围。

 

   而针对具体的软件项目，这个问题就可能需要用一本书去论述了。这里我只能举一个做过的UI项目的简单实例。在这个项目中需要一个显示时间的控件。对于这样一个任务，我们首先要做的就是调查一下是否有没有相应控件或既有实现。因为程序员的职责是解决问题，而不仅仅是编代码。在得到否定答案后我们还有两种选择：一是从合适的既有控件类派生一个显示时间的控件类，重写描绘函数就O了。另一种方法就是通过组合已有控件实现预期的时间显示。这两种实现的UML图分别为：

a. 派生控件

b. 组合控件

   从设计粒度的角度看，本例中派生控件的最小单位就是显示时间的控件，而组合控件的最小单位是构成时间显示的各个文本显示控件。虽然两种方法都解决了时间显示这个特定问题，但组合控件要比派生控件有更细的粒度。具体选择哪种方法就需要考虑灵活性、实现难度等因素。我当初选择了组合控件的方法，因为这样更灵活也更容易实现。同时我看到过之前解决类似问题的时候采用了派生控件的办法。做了选择就说明个人有了自己的答案。但若要真正给大家做个推荐，我觉得自己还需要更多积累和领悟。

 

   一杯沙子的美在于其亲密无间，而一杯石头的美则是实而不满。但对于具体的项目，粒度的选择可能不会仅仅在一杯沙子和一杯石头做一个二元选择，更多的选项可能会是沙中夹杂着石头或者石中混合着沙子，因此粒度的把握就更加地复杂和微妙。只要做软件就无法绕过这样的一个问题。只有多思考，多总结，多领悟，才能针对不同的项目调和出一杯合适的粒度的“沙石混合物”。

 

转自：http://bj007.blog.51cto.com/1701577/334110