包的设计原则

包的设计.
- 通过把类组织成package,可以在更高层次的抽象上理解设计.通过包来管理软件的开发和发布.
- 由于类之间的相互依赖关系,包之间会产生依赖关系.包的依赖关系展示了APP的高层组织结构.
粒度:内聚性."自顶向上"的将类划分到包中
- Reuse-Release Equivalence Priciple(REP).
  - 重用的粒度就是发布的粒度.
  - 重用类库时,我们要求author维护Code,同时在接口和功能改变时通知我们(同时我们有拒绝改变的权利).
  - 重用性必须基于包,可重用的包必须包含可重用的类.包中的所有类应该对于同一类用户来说都是可重用的.
- Common-Reuse Principle(CRP)
  - 趋向于共同重用的类应该属于同一个包.
  - 如果依赖于一个包,那么应该依赖于该包中的所有类.否则将要进行不必要的重新验证和发布(当不依赖的部分变化时).
  - 相互之间没有紧密联系的类不应该在同一包内.
- Common-Closure Principle(CCP)
  - 一个包不应该包含多个引起变化的原因(SRP的包规定).
  - 通常,可维护性是重于可重用性的.应该将可能由于同样的原因而更改的类共同聚集在一个包内.
- 选择包中的类时,要考虑可重用性与可开发性之间的反作用力.
稳定性:耦合性.
- Acyclic-Dependencies Principle(ADP)
  - 包的依赖关系图中不允许出现环.
  - Weekly Build.
    - 用于中等规模项目,平时在私有拷贝上Code.周五Build.但是之后,为了保持效率,就必须要不断地延长构建周期.
  - Eliminating Dependency Cycles
    - 把开发环境划分成可发布的包.分别开发各个包.以小规模增量的方式进行集成.
  - 包依赖关系图中环依赖造成影响
    - 环上的所有包会共同组成一个大包,彼此之间的发布要完全一致.
    - 测试一个包时需要引入和编译的包的数量会增长.使用UT可以提现.
    - 存在环时,很难确定包构建的顺序.
  - 解除依赖环
    - 抖动:Jitters.
      - 随着APP的增长,包的依赖关系结构会抖动(需求更改时)和増长(新增Package).
自顶向下的设计
- 包的依赖关系不能描绘APP的功能.它只是APP可构建性的映射图.
- 开始时,不设计包的结构.包结构是随着系统的增长,变化而逐步演化的.
- 当类越来越多时,开始关注CCP,将可能会一同变化的类放在一个包中.
- 之后,使用CRP来知道可重用元素的包组合.
- 最后,当环出现时,使用ADP.从而会导致包的抖动.
- 包的依赖关系是和系统的逻辑设计一起增长和演化的.
Stable-Dependencies Principle(SDP)

朝着稳定的方向进行依赖.
为了可维护性,易变性是必须的.对某些变化敏感的包,可以设计成可变的
对于一个期待可变的包,不应该让一个难以更改的包依赖于它.否则,它也会变成不可变的.
软件的反常特性:对于一个易变的包,创建一个对它的依赖就可以使其变得难以更改.
Stability

稳定性和更改所需的工作量有关.
稳定性度量
- 输入耦合度(A:外部依赖于内部),输出耦合度(E). 不稳定性(I). I= E/(A+E).
- [0,1].0代表具有最大的稳定度.
- 一个包的I值应该大于它所依赖的包的I值.I顺着依赖的方向减小.
并非所有的包都应该是稳定的.
- 应该把封装系统高层设计的软件放入稳定的包中(I=0).
- 同时,为了让其有灵活性,经受得起变化.使用抽象类.

Stable-Abstraction Principle(SAP)
- 包的抽象程度应该和其稳定程度一致.
  - 一个稳定的包应该是抽象的,这样稳定性不会使其无法扩展.
  - 一个不稳定的包应该是具体的,不稳定性使其内部的具体代码易于更改.
- SAP+SDP构成了包的DIP原则.依赖应该朝着稳定的方向进行+稳定性意味着抽象性=>依赖应该朝着抽象的方向进行.
- 包的灰度(shades of grey):允许包是部分抽象,部分稳定的.
- 包抽象性度量:A=a/c.抽象类的数目/类的总数.
- Pain区域
  - DB Schema.很高的易变性,同时非常具体,高度被依赖.所以APP和DB之间的接口很难定义.对DB Schema的更新很痛苦.
  - 工具库.string.

[Agile Software Development(Principles,Patterns,and Pracitices)]