java包的设计原则整理总结

前3个原则关注包的内聚性，这些原则能够指导我们如何把类划分到包中。后3个原则关注包的耦合性，这些原则帮助我们确定包之间的相互关系。

包的内聚性原则--粒度

1,重用发布等价原则

一个包的重用粒度（granule of reuse）可以和发布粒度（granule of release）一样大。我们说重用的任何东西都必须同时被发布和跟踪

a,由于重用性必须是基于包的，所以可重用的包必须包含可重用的类。因此，至少，某些包应该有一组可重用的类组成

b,如果一个包中的软件是用来重用的，那么它就不能再包含不是为了重用的目的而设计的代码。一个包中的代码要么都是可重用的，要么都是不可重用的

c,一个容器类库是可重用的，一个金融方面的框架也是可重用的。但是，我们不希望把它们放进 同一个包中。很多希望重用容器类库的人可能对于金融框架根本不感兴趣。因此，我们希望一个包中的所有类对于同一类用户来说都是可重用的。我们不希望一个用 户发现包中所包含的类中，一些是他所需要的，另一些对他却完全没用

2,共同重用原则

a,一个包中所有类应该是共同重用的。如果重用了包中的一个类，那么就重用包中的所有类

b,一个简单的例子是容器类以及与它关联的迭代器类。这些类彼此之间紧密耦合在一起，因此必须共同重用。所以它们应该在同一个包中

3,共同封闭原则（CCP）

包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对包中的所有类产生影响，而对于其他的包不造成任何影响

a,这是单一职责原则（SRP）对于包的重新规定。正如SRP规定的一个类不应该包含多个引起变化的原因那样，这个原则规定了一个包不应该包含多个引起变化的原因。

b,可维护性的重要性是超过可重用性的。如果一个应用中的代码必须更改，那么我们宁愿更改都集中在一个包中，而不是分布在多个包中。如果 更改集中在一个单一的包中，那么我们仅仅需要发布那一个更改了的包。不依赖于那个更改了的包的其他包则不需要重新验证或重新发布

c,如果两个类之间有非常紧密的绑定关系，不管是物理上的还是概念上的，那么它们总会一同进行变化，因而它们应该属于同一个包中，这样做会减少软件的发布、重新验证、重新发行的工作量

d,。我们所设计的系统应该对于我们经历过的最常见的变化做到封闭

e,CCP通过把对于一些确定的变化类型开放的类共同组织到同一个包中，从而增强了上述内容。因而，当需求中的一个变化到来时，那个变化就会很有可能被限制在最小数量的包中

 

包内聚性总结

 

　　过去，我们对内聚性的认识要远比上面3个原则所蕴含的简单。我们习惯于认为内聚性只不过是指一个模块执行一项并且仅仅一项功能。然而，这3个关于包内聚性的 原则描述了有关内聚性的更丰富的变化。在选择要共同组织到包中的类时，必须要考虑可重用性与可开发性（develop ability）之间的相反作用力。在这些作用力和应用的需要之间进行平衡不是一件简单的工作。此外，这个平衡几乎总是动态的。也就是说，今天看起来合适 的划分到了明年也许就不再合适了。因此，当项目的重心从可开发性向可重用性转变时，包的组成很可能会变动并随时间而演化。

===============================================================================

包的耦合性原则--稳定性

1，无环依赖原则（ADP）

a,无论从哪个包开始，都无法沿着依赖关系而回绕到这个包。该结构中没有环

b,当发布一个新版本时，会很容易找出受影响的包：只需逆着依赖关系指向寻找即可。

c,果依赖关系图中存在环，就很难确定包构建的顺序

d:在发布整个系统时，是自底向上进行的

e,解除依赖的方法：

e-1解除依赖环

a,使用依赖倒置原则（DIP）。

b,新创建一个A和B都依赖的包

2，稳定依赖原则（SDP）

a,朝着稳定的方向进行依赖。

b,对于任何包而言，如果期望它是可变的，就不应该让一个难以改变的包依赖于它！否则，可变的包同样也会难以更改

c,通过遵循SDP，我们可以确保那些打算易于更改的模块不会被那些比它们难以更改的模块所依赖

d,如果一个系统在所有的包都是最大程度稳定的，那么该系统就是不能改变的

e,可改变的包位于顶部并依赖于底部稳定的包。把不稳定的包放在图的顶部是一个有用的约定，因为任何一个向上的箭头都意味着违反了SDP

f,解决办法 DIP来修正这个问题

g，系统中的某些软件不应该经常改变。该软件代表着系统的高层构架和设计决策。我们希望这些构架决策是稳定的。因此，应该把封装系统高层设计的软件放进稳定的包中。不稳定的包中应该只包含那些很可能会改变的软件

3，稳定抽象原则（SAP）

a,包的抽象程度应该和其稳定程度一致

b,该原则把包的稳定性和抽象性联系起来。它规定，一个稳定的包应该也是抽象的，这样它的稳定性就不会使其无法扩展。另一方面，它规定，一个不稳定的包应该是具体的，因为它的不稳定性使得其内部具体代码易于更改。

c,因此，如果一个包是稳定的，那么它应该也要包含一些抽象类，这样就可以对它进行扩展。可扩展的稳定包是灵活的，并且不会过分限制设计

d,SAP和SDP结合在一起形成了针对包的DIP原则。这样说是准确的，因为SDP规定依赖应该朝着稳定的方向进行，而SAP则规定稳定性意味着抽象性。因此，依赖应该朝着抽象的方向进行。

===============================

设计模式 和设计原则关系

先不考虑设计模式，一切简单至上。毕竟使用了设计模式就或多或少地增加了软件的复杂性（闻到一些复杂性的臭味没？）。随着程序规模的扩大，需要应用面向对象设计原则对软件中的模块进行抽象和解耦时，再把它回归为模式