单元功能代码的就地原则

单元是逻辑上的，单元这词还真不好拿一个比较准确的句子去概述，在实际的代码编写过程中，究竟怎么划分单元，是一个很有意思的问题，拿一个DAO的编写来探讨。

 

写一个DAO的时候，先写接口，再写实现类，程序员基本是这么干的，那么DAO中需要用到的SQL语句放在什么地方呢？不外乎这四种做法

1. 在接口中定义静态公共变量，并初始化之
2. 在实现类中定义静态公有(或私有)变量，并初始化之
3. 在外部资源文件中定义SQL语句，在实现类中合适的时机读取该SQL语句
4. 在实现类的方法中定义局部变量，并初始化之
   

代码编写的步骤是先写SQL，然后在函数中执行，并返回结果。在理想的情况下，SQL是正确的，在函数中执行也没有遇到问题，这个过程只需要一遍即可完成。但是这种情况极少能出现，一个函数编写完到调试完毕，输出正确的结果，怎么的说也要在检查SQL语句，调试函数内语句之间切换个好几次的，如果初次的SQL语句不正确，还要对其进行修改。

 

因此，前面所说到的单元问题在这个时候产生了效应，第一种方法需要修改接口中的静态公共变量，也就是要切换到另外一个类中，这个时候，类可以看着是一个单元。函数本身也是一个单元，在这种做法中，总共需要跨越两个单元。

 

第二种方法，修改SQL，需要跨越函数本身，跨越了一个单元。

 

第三种方法，如果需要修改SQL，需要到相关的资源文件中去修改，假如读取SQL文件的类也算一个单元，那么可能会有一些额外的成本去调试读取的SQL是否正确，对SQL语句进行资源统一编号。这样算下来，修改SQL最多需要跨越四个单元。

 

第四种方法，本地的局部变量，直接修改，对其他的模块无任何影响。前面三种做法中，假如SQL被多个模块所引用，修改SQL时，也修改了另外一个实现函数的逻辑。因此，耦合性很大。

 

但前三种方法在代码的设计过程中，经常被用到，不止如此，第四种做法还经常被嘲笑为低手的做法。但是仔细的分析后，第四种做法恰恰是在代码设计上一个好的做法，它遵循了修改其本身对其他单元不影响的原则，修改其本身时，也只要在其单元内部进行。这个原则我们称之为单元功能代码的就地原则。

 

<完>

 

 

评论

1 楼 niva 2012-09-30  

不错 好文 
思想与grasp中的 信息专家模式不谋而合 你可以和大师媲美了