《敏捷软件开发》读书笔记（2）
包的划分原则和度量方法
以下原则中，前三个有关粒度，关注于如何把类划分在包里，是自底向上的设计，是关于包的内聚性设计，但是要考虑可开发性和可重用性两者的平衡；而后三个有关耦合，关注包之间的关系，关于包的稳定性设计，是自顶向下的设计思考。
重用发布等价原则REP
重用的粒度=发布的粒度，重用的粒度就是发布的粒度，为重用而发布的包中，不应该包含任何不是为重用而设计的类，也就是不应该包含任何业务定制、环境定制多代码。另外，也要考虑划分，不能强迫使用者引入他们不需要的类。
共同重用原则CRP
一个包中的所有类应该是共同重用的，如果重用了包的一个类，那么就要重用包中的所有类。重点是，相互之间没有紧密联系的类，不应该放在一个包中。否则，要么可能增加软件大小（apk这种），要么是一些不相关的类的更新，会导致所有依赖的地方被迫更新、验证，即使他们完全没有用这些类。
共同封闭原则CCP
一个包多所有类，应该对同一类变更是共同封闭的，也就是会为了同一个原因而修改，不应该包含多个引起变化的原因。一个需求变化到来时，应该将变化封闭在一个包中。（业务复杂，至少在修改问题时，不应该到处修改）
无环依赖原则
没啥好说的，包之间不能出现循环依赖，否则会出现无法构建、晨后综合征、测试困难、构建时间长等问题，可以用如下两个方式解决循环依赖：抵赖倒置、增加一个包，让两个模块都依赖新的包。
不能自顶向下的设计包结构，应该随着系统增长和变化逐步演化
稳定依赖原则SDP
向着稳定的方向进行依赖。让易于修改的包依赖稳定的包，否则会让稳定的包被迫修改，或者让易于修改的也很难修改。如何定义稳定性：决定模块是否易于修改，和修改的工作量有关。稳定性度量：out/out+in。稳定性应该随着依赖方向递增。（审视一下UI包的修改稳定性）。通常可以通过抽象接口或者DIP，让稳定的包依赖接口。
稳定抽象原则
一个稳定的包应该是抽象的，一个不稳定多包应该是具象的。越稳定的包，应该越抽象。抽象度度量：抽象类/所有类。
如何确定包的划分是合理的
主序列：稳定且抽象-不稳定且具象的一条线，大部分类应该在靠近这个区域内一定范围内。（可以考虑一下项目里每个包的情况，识别远离主线的那些包是什么情况）
以下方式可以度量包的划分合理性
-
关系内聚性：（包内类关系数目+1）/包内类总数，范围0-1，越接近1内聚性越好。
-
输入耦合度：依赖该包中，其他包中类的数目。
-
输出耦合度：该包中的类，依赖其他包中的类的数目。
-
抽象性和通用性：抽象类数目/总类数目，范围0-1，越接近1越抽象越通用。
-
不稳定性：输出耦合/总耦合，范围0-1，越接近1越稳定。
-
到主序列的距离：到主序列的距离，约接近0越好。
薪水支付系统的实践
从需求开始初步的设计和实现
-
先通过简单用例分析，得出系统的结构，并且在过程中找出潜在的抽象，不要一开始就关注于数据库细节。这个过程会比较快速，提供一个整体的设计思路可以展开工作。
-
实现过程，按照设计-用例-编码过程逐步实现，并且在过程中注重抽象和封闭，注意每个类的职责分配和关心点是否合理。
逐步划分，利用设计模式和划分包的原则，优化结构
-
运用依赖倒置原则，划分包之间的依赖，让具体实现或者细节依赖于主要抽象，大部分可执行代码位于很少依赖或者没有依赖的包中。并应用公共封闭原则CCP，让每个包中任意一个类的修改，不会影响到其他包。
-
应用重用发布等价原则，也就是一个包中的类，要复用一个就全部被复用。这要求包中所有类是内聚的，不容易被轻易分割开，一同重用。
-
包的耦合和封装，可以利用语言特性，将包的部分类导出，部分类隐藏。
-
用对象工厂，解决跨包依赖具体实现的问题
来源：CSDN
作者：drumdream
链接：https://blog.csdn.net/drumdream/article/details/103846403