作为一个开发人员，我们知道一个灵活的系统能够保证系统良好的兼容性及扩展性。当提及系统的灵活结构这一话题时，我们通常都说到类的关联，而很少提到系统中package的结构。事实上，认真设计package结构对系统的灵活性有着很重要的作用。
在本文中，我们将讨论java程序中设计package关联的重要性。在后面的章节里，我们会陆续讲述当设计package关联时一些具有指导性的启发式知识。
了解更多的Java知识
你可以阅读本站关于Java的文章，以学习更多的Java知识。
Package关联
当设计一个系统的package结构时，通常很少花时间在packages之间的关联设计上，Packages只是被认为是类的容纳器。事实上，package之间的关联才是许多体系模式的基础。肤浅的理解体系模式的粗枝断叶不能说明这些模式完整地匹配程序的内容，相反，理解最基本的概念，我们才可以表达很多功能强大的体系模式。
设计package关联
使用标准统一模型语言(UML)可以很轻易地描述packages之间的关联。两个packages之间的关联称为package从属。在图A中，我们可以看到描绘client和service的两个packages，其中每一个packages包含一个简单的类。在package client一端，类的名称为client，在package service一端，类的名称为service。点画线连接了这两个packages，这说明client package中至少有一个类与service package中的一个类有关联。这一点画线即为一个从属关系，也是一个UML模型成员。这一点画线的方向是单一的，说明service package中的类与client package中的类没有结构上的关联。
Figure A
Package dependency diagram
仔细查看两个类之间的关系，显然，service中的类的改变一定会影响client中的类，因为这两个类之间有关联。相反则不然，client中类的改变不会影响到service中的类，因为点画线是有方向性的。Packages之间的从属关系与类之间的关系是一致的。因为package client对package service有一个依靠关系，service package内容的改变一定会影响到client package中的内容。
这些package之间的关联的值具有两重意思。第一，程序中的packages一定比类少。图A中，我们可以看出，client package内容的改变不会影响到其他的package，因为没有其他的package依靠于client package。我们在开发过程中可以集中精力在类的关联及类改变所带来的影响上。
Package关联在系统设计中占有很重要的部分。Package与类的关联设计会生成各自独立部分。类关联提供很细微的结构查看，而package则提供相对粗糙的查看。由于这些查看结果代表相同的系统，查看之间要相互匹配，假如不匹配则一定要修正。
Package关联应该是单一方向
开发人员应该力求于关联的最小程度。双向关联会增加这些package的联系，减小系统的完整性。双向关联出现形式有两种：直接或间接的形式。直接形式意味着两个package之间都有依靠关系，如图B中的左边所示。
Figure B
Package relationships
直接双向关联比较轻易识别并轻易修正。转移一个package中的成分到另一个新建的package会生成新的从属关系，如图C的左边所示。
Figure C
Direct bidirectional relationship
间接双向关联比较难于识别。最轻易的识别方法是，生成代表所有packages关联的一个图形，选择最简单的package作为起始点，顺着两两之间的从属关系查找，假如最后又返回到起始点，则这一方向即是间接双向关联。
注重的要害事项
让我们总结一下设计package关联时应该注重的要害事项。
Package之间的关联——package之间的单一方向会减小系统的关联，并且轻易维护。
双向关联的影响——双向关联会限制很多功能，并且表现出比较差的package升级性。
层——通常的，级别高的层会依靠级别低的层。所以级别低的层会很少与其他层有关联，这就增加了packages的使用功能。
预见功能
package关联通常是程序完成了以后才记起的想法。一个优秀的系统不仅能反映出良好的类弹性，而且也反映出良好的package弹性。经过认真考虑的package关联将会产生比较少的错误。设计package关联时非凡注重的是：力求单向关联。因为它能减少系统的连接，增加系统的灵活性，这样就可以提高系统的维护性和稳定性。
