Java包的命名与划分

同事昨天接收到这样一份任务：梳理现在Android项目中“顶层包”的依赖关系，从而进行层次结构的梳理。

在一起的探索的过程中，发觉收获还是蛮大的，灵感突发，马上梳理于此。

（一）使用Java包的目的

在了解做一件事之前，我们需要了解做这件事的目的。而使用Java包的目的大概如下：

1    对类进行归类，便于开发查找。

2    将软件在代码层面上模块化，提升可测试，可维护性。

3    将软件在代码层面上层次化，提升可读性，层次分明。

（二）包的命名

要梳理包的依赖关系，首先我们要把握包的命名规则，一旦名字取的不好。在梳理包依赖关系时，便将各种纠结。

Java的包是多个类的集合。包的命名，或以独立功能为准，或以层次划分为准。

（三）命名与依赖关系

项目中以独立功能命名的包，往往倾向被其它包依赖，而不能依赖其它包。

项目中以层次划分的包，往往倾向于向下依赖，而不能依赖于上层包。

总的来说，“包依赖关系体现出软件层次划分（竖向），功能模块划分（横向）”。

（四）获取代码中的包依赖关系

a.使用Java编译报错特性：同事通过Eclipse工具，对依赖包进行“refrector”操作(不勾选“update reference”选项)，查看编译时的其它包报错，这样去确定哪些包依赖此包。从而逐个通过画图工具把包依赖关系绘制出来。（注：这种方式比较取巧，幸亏项目中的包并不是很多，同事花了30分钟就搞定了）

b.使用Eclipse插件modelgoon：http://www.oschina.net/p/modelgoon。利用此工具可以方便的导出包依赖关系。（注：同事觉得非常简单好用）

（五）对“单向依赖”的追求

从包依赖关系图中，我们通过箭头呢，我们可以清晰的看到：一个包被哪些包依赖，而这个包又依赖哪些包。一般呢，一个包更倾向于“被单向依赖”，这意味这个包是可独立，可维护。对于软件测试来讲，单向依赖的包更容易进行单元测试。额外的，如果此包被广泛使用，我们更多会将该包作为一个开发组件，并以一个独立项目的方式来对其进行维护，当然这只是后话了。

吐槽：一个三年开发过程的项目，可能才诞生出一个独立的开发组件。而这种组件，除非牛b闪闪，前无古人，后无来者。要不然随便来一个第三方库都可以把你替换掉。 

（六）消灭“循环依赖”

“循环依赖”是指两个包之间互相依赖。如何消灭“循环依赖”呢?，我归类出以下三种方法：

1  拆迁法。

A包的某些类或某些方法规划不合理，应该将其放在B包或者放在C包。

2  合并法。

B包所包含的业务属于A包的范围。将B包作为A包的子包。

3  依赖于接口法。

A包依赖B包，B包依赖A包的特定函数方法。这样可以通过依赖于抽象，来执行包与包之间的解耦。

（七）附转：包划分的几个小原则：

1  一个包要么包含独立的功能，要么代表某层的功能。否则包的划分就没有意义，且查找起来很混乱。

2 某类的子类。（比如接口或者虚类不同的实现）应当单独放到某个包中。

3 假设A包依赖B包，那么B包不应该依赖A包。例如不应当在B包中出现包含A包中类的接口或属性。如果必须增加接口，则应当使用普通类或者B依赖的包中的类组织信息。

否则提取B包中的功能时，会牵扯出不需要的A包。

4 如果A包，B包均依赖于C包，则包c不应当为A或B的子包。