Gemini测试小工具¶

在上学的时候就听老师说，写程序要做到低耦合。这话是牢牢的记在心里了（我还算是个乖学生）。可是在具体的编程过程中有犯糗了。犯糗原因就是对于常见耦合分辨不清、不知道在我的应用中那些耦合可以接受、那些耦合在特定场合可以接受、那些耦合要尽量避免、最重要的就是不同的耦合在代码中如何表现会有如何的影响。

还好这些问题近期在一本叫《代码大全》的书里面找到了（插一句，如果你还没有听说过这本书，赶紧，一定要赶紧打开Google，去Google一下）。

书中提到（中文版 p101）了常见的耦合的种类有如下几种：

l      简单数据参数耦合

l      简单对象耦合

l      对象参数耦合

l      语义上的耦合

对于简单数据参数耦合比对象参数耦合更有灵活性书中在耦合标准－灵活性（p100）中进行了描述。并得出对象参数耦合要比简单数据参数耦合的耦合程度要高。

但是在使用的过程中发现很多场合如果使用“简单数据参数”的话，函数的参赛数列表会很长。这个声明的时候倒是没什么，但是在调用的时候就有可能写错参数的个数（这个还好 ide会告诉我们），参数写的顺序不正确（这个就比较郁闷了，容易出bug而且还不容易找）。

我想如果能用“简单数据参数”就尽量使用，在不同的场合考虑使用“对象参数”。为了这个问题我曾经和我的同事狂吵过。所以印象很深。

最有感触的就是上海新开通的轨道交通4号线。我乘坐的区间是临平路~火车站。在这个短短的几站路的过程中。我看到了地铁（地下），清轨（空中），铁路（地面上）这三种方式。从临平路到宝山路是采用的新建的地下轨道。当到了宝山路这一段是就充分利用3号线已有的资源。这就是我看到的清轨了。进了火车站后又直接利用火车的轨道。完成着一段路程。真的可算做到充分利用现有资源。

其实在我们现在的软件开发的过程中。完全是可以借鉴这个观点的（其实很多地方已经这么干了）。

但是在利用现有资源的前提是要了解现有资源。评估他带来的好处。
如果能够解决评估现有资源和采用现有资源的总代价和采用传统方式的代价的比较。那就比较爽了。现在我对这个一点头绪都没有。欢迎你的任何意见。谢谢了先。