典型的J2EE项目，package的设计有成熟的套路可循，如分为domain、dao、service、action等等，职责已经分解的比较单一和 清晰，循环依赖这样的情况出现并不多。而在一般的java项目，如服务器程序、客户端程序和通用性框架的开发中，包的设计并没有套路可循，毕竟由于应用和 业务种类的不同，想得出通用性的设计套路是不大可能的。这时候遵循一些原则比之生搬硬套更为重要。在《敏捷软件开发》一书中对包的设计有深入的讨论，虽然 针对的是发布的二进制包而言，但是对于java package的设计同样有借鉴意义，如对包的内聚性、可重用性、稳定性的强调，对于依赖的探讨，这些都是比较笼统的概念，不是那么直观，需要在实际运用 中认真归纳和重构，向这些原则靠拢。
   我所想到一个比较直观的方法就是：对于一个包的描述，你是否能用一句简明扼要的话概括，也就是包的功能或者说介绍能否做到简明扼要，这是衡量一个包的设计 是否合理的最简单的方法。如果可以，显然这个包的内聚性很好，所有的类都服务于一个目的，从而带来了重用的可能(其实我对重用性并不感冒，除了工具类之外真正能重用的东西少之又少，内聚性才是需要关注的）；反之，这个包可能承担了太多的职责或者依 赖过多，仔细的重构和分离是需要做的。包的设计同样要遵循接口分离的原则，将接口与实现隔离在不同的包之中，客户程序就不会知道具体的实现，并且也保证了 实现对接口的单向依赖。当然，这时就需要引入工厂类、插件或者IOC容器来负责实例化实现类。