类(dichotomy)方法。这是在你的组织中应用代码复用能力，以及一次性的消除代码复制问题的关键所在。

这种代码的归类方法运用到package上的时候，逻辑上需要从最高级别上分为通用（复用）package的主分支以及非通用（非复用）（比如：应用特定的）主分支。

举个例子，在过去的五年中，我已经把org.lv这个最高级的命名空间分为了org.lv.lego和org.lv.apps这两个子空间。（lv并不代表什么，只是我最初的命名）这些基本的高级别的分支在以后的日子里面又分成了更多的子空间。比如lego分支目前分成如下的一些子空间：

org.lv.lego.adt
org.lv.lego.animation
org.lv.lego.applets
org.lv.lego.beans
org.lv.lego.comms
org.lv.lego.crunch
org.lv.lego.database
org.lv.lego.files
org.lv.lego.games
org.lv.lego.graphics
org.lv.lego.gui
org.lv.lego.html
org.lv.lego.image
org.lv.lego.java
org.lv.lego.jgl
org.lv.lego.math
org.lv.lego.realtime
org.lv.lego.science
org.lv.lego.streams
org.lv.lego.text
org.lv.lego.threads

请注意的是，基本上所有这些包结构的逻辑内容都自我证明了它们是经过仔细选择后的结果，并且也是从字面上就可以分辨出它们的含义（可以和java.*结构做对照）。这一点对于释放可复用代码真正的潜力作用是非常关键的，比如那些可复用的逻辑、程序、常量、类以及接口。很差的包命名，就象很差的类/接口的命名一样，会对它们的使用者产生歧义并且破坏资源的复用潜力。

在这些较深层次的包级别上，您仍然需要对如何进一步组织您的包结构非常的小心。

这里是第二条黄金规则：

黄金规则二
保持分等级的包结构
总是试图创建象平衡的、不规则形状的树结构那样的包层次。

如果你的包层次中的某些层次最终形成（退化为）线性结构，那表明了你并没有正确的使用Java包特性。经典的错误是简单的将项目包罗列在你的最高层应用包分支下面，比如在我的org.lv.apps包。这是错误的使用方式，因为它并不是层级结构的。线性罗列对于人脑来说是难以记忆很长时间的；而层级结构却正是适应我们大脑的神经系统网络结构的。

项目总是能由关键原则来进行归类，这原则或者说观念应该在你的Java包层次中反应出来。下面是我的org.lv.apps包目前是如何进行细分的：

org.lv.apps.comms
org.lv.apps.dirs
org.lv.apps.files
org.lv.apps.games
org.lv.apps.image
org.lv.apps.java
org.lv.apps.math

很明显，你们的细分肯定和我的不相同，但是重要的是从大处考虑并且在脑子里始终保留对将来的扩展能力。深层次的包结构是有益的。而浅层次的则不然。

上一页  [1] [2] 

在google里搜索更多挖掘package声明的潜力(一)

	Web www.51ec.org

上一篇信息学院： Jsp连接数据库大全

下一篇信息学院： 用utraEdit，编译并运行java