zoukankan      html  css  js  c++  java
  • 包的设计原则

    • 包的设计.
      • 通过把类组织成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)]

  • 相关阅读:
    setState 是异步吗?
    React优化点滴
    JS原型,作用域,this,闭包
    Webpack 模块化打包优化
    JS异步编程
    Web网络安全
    Http2.0和Http3.0
    Http协议基础
    Harris算子以及未来的规划...
    剑指offer 二维数组查找
  • 原文地址:https://www.cnblogs.com/robyn/p/3470861.html
Copyright © 2011-2022 走看看