细粒度模块划分技巧：通用机制的框架化

软件系统中的”机制”是指预先定义好的、能够完成预期目标的、基于抽象角色的协作方式，既包含协作关系也包含协作流程。理解”机制”要先分清它和”协作”的区别：”协作”是多个对象为完成某种目标而进行的交互；”机制”是特殊的协作，只有基于抽象角色的协作才算得上机制——基于接口（和抽象类）的协作是机制，基于具体类的协作则算不上机制。这个区分的实用价值在于识别一类隐蔽的重复代码：如果没有提炼出机制，机制往往表现为一种隐式的重复代码——不同语句直接比较可能并不相同，只是引用的变量不同，但大段的语句块结构其实完全一样；一旦提炼出机制，它在编程层面就体现为”基于抽象角色（面向对象里就是接口）编程”的那部分程序。划分模块时应该把通用机制框架化，而框架的本质是”可以通过某种回调机制进行扩展的软件系统或子系统的半成品”——”半成品”这三个字是框架的核心特征。理解框架为什么值得投入，要先看清”软件重用”内在的一对矛盾：重用几率大小和重用所带来的价值量大小成反比——软件单元粒度越大，重用带来的价值量越大，但被重用的几率越小；反之粒度小的软件单元被重用的几率大，但重用带来的价值量小。框架的智慧正在于打破这对矛盾：把容易变化的部分封装成扩展点、辅以回调机制纳入框架的控制范围，从而在兼顾定制开销的同时，让重用所带来的价值量最大化——这就是为什么”粒度大、又能被广泛重用”这个看似矛盾的目标，只有通过框架化才能同时达成。通用机制框架化对架构牢固性不可或缺，框架之于整个软件系统，就像大厦的供暖、供电、排水设施——专门解决整座大厦的通用问题，软件框架的具体例子有数据库管理机制、事件通知机制、事务服务机制、权限确认机制等，为系统其他部分提供行为支持。