软件系统的组件设计

组件是整个软件系统在部署过程中可以独立部署的最小实体。哪些类应该被组合成一个组件？下面会讨论与构建组件有关的基本原则以及组件之间的关系。

一、组件聚合

组件构建原则是指导如何将各组件组合成独立部署的软件系统。组件聚合是常用的组件构建方法。

组件聚合是指将多个相关的组件组合在一起，形成一个相对独立的、可交付的子系统或模块。

组件聚合的优点：

提高可维护性：通过组件聚合，将相关联的组件放在一起，减少代码的耦合度，提高代码的可维护性。当需要修改某个组件时，避免在其他模块中查找和修改代码，降低出错的风险。

提高可扩展性：通过组件聚合，可以将系统拆分为多个相对独立的部分，每个部分都可以单独扩展和升级。使系统更容易适应未来的需求变化。

提高开发效率：通过组件聚合，可以将开发任务分解为多个小的子任务，每个子任务相对独立，可以由不同的开发人员同时进行开发，提高开发效率，缩短开发周期。

组件构建的三个原则

REP：复用/发布等同原则

REP是关注重用的原则。核心思想是将通用功能封装为可重用的组件，以便在多个应用场景下使用。组件中的类和模块必须是紧密相关的。

要点

识别可重用的组件：分析现有系统和业务需求，找出具有通用功能的组件，如用户信息、日志记录、数据访问等。

设计可重用组件接口：为识别出的可重用组件定义清晰的接口。

实现可重用组件代码：为可重用组件编写高质量代码，确保具有可扩展、可维护和可测试。

文档化可重用组件：为可重用组件编写详细的文档，包括使用说明、参数说明和示例代码。

软件复用的最小粒度应等同于其发布的最小粒度。

建议

模块化设计：将系统分解为独立的模块，每个模块专注于一个具体的功能或领域。这有助于识别和构建可重用的组件。

设计清晰的接口：在组件内部，确保设计清晰、简洁的接口。这样可以降低组件的使用难度，提高可重用性。

版本控制：使用明确的版本控制机制管理组件的发布。确保版本升级时的向后兼容，降低对已有系统的影响。

自动化构建和发布流程：建立自动化的构建和发布流程，以减少发布过程中的错误，提高组件的发布效率。

CCP：共同闭包原则

CCP 是关注耦合的原则。将由于相同原因而修改，并且必须同时修改的类放在一起。

要点

避免硬编码：将硬编码分解为独立的功能模块，使每个模块具有明确的职责和边界。

使用接口而非实现：通过接口定义组件之间的交互方式，不直接依赖实现类，可降低组件之间的耦合度。

使用事件或消息传递：通过事件或消息传递实现组件之间的交互，降低耦合度。

避免全局状态：全局状态会使组件之间的依赖增强，降低系统的灵活性和可维护性。导致潜在的错误和难以维护。

松散耦合：使用依赖注入、事件驱动等方式降低组件之间的耦合度。确保修改一个组件不会对其他组件造成影响。

对于大部分应用来说，可维护性的重要性远高于可复用性。

CRP：共同复用原则

CRP是关注内聚的原则。不要依赖不需要的组件。是ISP原则的普适版。

要点

功能单一化：每个组件应只完成单一的功能，避免将多个功能混杂在一起。这有助于提高组件的内聚性。

模块化设计：将代码分解为模块，模块有清晰的职责和边界，提高内聚性和可读性。

减少条件语句：避免使用过多的条件语句，尽可能将条件逻辑抽象为方法，减少代码复杂度，提高内聚性。

使用设计模式：用常见的设计模式来组织代码结构，提高代码的内聚性和可维护性。

ISP原则是建议不依赖带有不需要的函数的类。CRP原则是建议不依赖带有不需要的类的组件。

思考

组件聚合原则和软件设计原则的区别？

组件聚合张力图

上图即三个基本原则的张力图，张力线描述了忽视对应原则的后果。

基于对REP 、CCP 、CRP三个原则的理解，会发现这三个原则之间彼此是竞争关系：REP和CCP是黏合性原则，基于这两个原则会让组件变得更大。但CRP是建议拆分原则，会让组件变小。

需要在这三者之间找到平衡，在团队能力水平、业务场景复杂度、发布流程等因素的动态变化中，根据团队状况进行动态调整。

总的来说，早期可以偏向REP和CCP，后期可逐渐朝着CRP的方向发展。需要在项目中灵活运用这些原则，结合具体情况做出合理的决策。

二、组件耦合

组件构建原则指导如何设计组件内容。而组件耦合原则是指导设计组件之间的关系。耦合是指组件之间相互依赖的程度，耦合度直接影响可维护性、可扩展性和可重用性。

组件耦合原则

无依赖环原则

循环依赖会导致难以独立的维护组件。并使得单元测试和发布流程也很困难。

通过依赖反转打破依赖环。从而保证系统是有向无环。

组件依赖结构图是应用程序在构建性和维护性方面的一张地图。其指导如何隔离频繁的变更。

稳定依赖原则

依赖关系必须指向更稳定的方向。可变更的组件位于顶层，依赖于底层的稳定组件。

稳定抽象原则

组件的抽象化程度与其稳定性保持一致。

SAP为组件的稳定性和抽象化程度建立了关联。该原则要求文档的组件应该是抽象的，这样它的稳定性就不会影响到扩展性。

将稳定依赖原则（SDP）和稳定抽象原则（SAP）两个原则组合起来，就等于组件层次上的DIP。

常见耦合类型

内容耦合：组件直接访问另一个组件的内部数据结构或直接调用其方法，耦合度较高，慎用。

控制耦合：组件通过调用另一个组件的接口来控制其行为，相对较松，是常用的耦合方式。

标记耦合：组件通过一组参数请求另一个组件执行特定操作，比较灵活。

外部耦合：组件与外部系统进行交互。这种耦合方式通常无法避免，但需要尽量减少对系统内部的影响。

控制组件耦合原则

最小化耦合原则：降低组件之间的耦合度，使组件尽可能独立工作。

接口耦合原则：通过接口定义组件之间的交互方式，而不是直接依赖实现类，以降低组件之间的耦合度，提高系统的可维护性和可扩展性。

依赖倒置原则：将依赖关系建立在抽象层面上，而不是在具体类上，使系统更灵活和可维护。

单一职责原则：每个组件只承担一个职责，避免一个组件承担过多职责而导致其他组件对其产生过度依赖。

耦合优化路径

在软件架构设计的过程中，需要定期对系统进行耦合度评估，如果出现高耦合，可以按照以下路径进行优化：

分解组件：将高度耦合的组件分解成更小的、更独立的组件，降低耦合度。

引入接口：通过接口来定义组件之间的交互方式，减少直接依赖实现类。

抽象依赖：将具体依赖抽象化，通过抽象层来控制组件之间的依赖关系，降低直接依赖具体类。

组件耦合原则对于软件架构的健壮性和可维护性至关重要。通过遵循组件耦合原则，构建灵活且可扩展的系统，提高系统的稳定性和可维护性。

架构可以实现两个维度的隔离。第一个是对各个角色根据单一职责进行隔离。第二个是应用依赖关系原则。这两个维度的隔离是为了将不同变更原因和变更速率的组件分隔开。譬如组件使用的角色不同导致变更的原因不同，组件的层级导致变更速率不同。

参考

《架构整洁之道–Robert C. Martin》