组件构建的三个基本原则

---

前言

         组件一般由哪些类组合成一个组件？这是一个非常重要的设计决策，应该遵循优秀的软件工程经验来行事。但不幸的是，我们对于这么重要的决策经常是根据当下面临的实际情况临时拍脑袋决定的。以下内容中，会对组件构建过程做一个简单总结，以了解组件构成的一些基本原则。
组件构建的三个基本原则：
REP：复用/发布等同原则
CCP：共同闭包原则
CRP：共同复用原则

---

一、REP：复用/发布等同原则

        原则基本描述：软件复用的最小粒度应等同于其发布的最小粒度。
        从软件设计和架构设计的角度来看，REP原则就是指组件中的类与模块必须是彼此紧密相关的。也就是说，一个组件不能由一组毫无关联的类和组件组成，它们之间应该有一个共同的主题或大致方向。
        一个组件中包含的类和模块还应该是可以同时发布的。这意味着它们共享相同的版本号与版本跟踪，并且包含在相同的发行文档中，这些都应该同时对该组件的作者和用户有意义。

二、CCP：共同闭包原则

        原则描述：我们应该将那些会同时修改，并且为相同目的而修改的类放到同一个组件中，而将不会同时修改，并且不会为了相同目的而修改的那些类放到不同的组件中。
        这其实是SRP原则（单一职责原则）在组件层面上的再度阐述。正如SRP原则中提到的“一个类不应该同时存在着多个变更原因”一样，CCP原则也认为一个组件不应该同时存在着多个变更原因。
        对于大部分应用程序来说，可维护性的重要性要远高于可复用性。如果某个程序中的代码必须要进行某些变更，那么这些变更最好都体现在同一个组件中，而不是分布于很多个组件中。因为如果这些变更都集中在同一个组件中，我们就只需要重新部署该组件，其他组件则不需要被重新验证、重新部署了。
         CCP的主要作用就是提示我们要将所有有可能会被一起修改的类集中在一处。也就是说，如果两个类紧密相关，不管是源代码层面还是抽象理念层面，永远都会一起被修改，那么它们就应该被归属为同一个组件。通过遵守这个原则，我们就可以有效地降低因软件发布、验证及部署所带来的工作压力。

三、CRP：共同复用原则

        原则描述：不要强迫一个组件的用户依赖他们不需要的东西。
        通常情况下，类很少会被单独复用。更常见的情况是多个类同时作为某个可复用抽象定义被共同复用。CRP原则指导我们将这些类放在同一个组件中，而在这样的组件中，我们应该预见到会存在着许多相互依赖的类。
        CRP原则的作用不仅是告诉我们应该将那些类放在一起，更重要的是要告诉我们应该将哪些类分开。因为每当一个组件应用了另一个组件时，就等于增加了一条依赖关系。虽然这个引用关系仅涉及被引用组件中的一个类，但它所带来的依赖关系丝毫没有减弱。也就是说，引用组件已然依赖于被引用的组件了。
        由于这种依赖关系的存在，每当被引用组件发送变更时，引用它的组件一般也需要做出相应的变更。即使它们不需要进行代码级的变更，一般也免不了需要被重新编译、验证和部署。哪怕引用组件根本不关心被引用组件中的变更，也要如此。
        因此，当我们决定要依赖某个组件时，最好是实际需要依赖该组件中的每个类。换句话说，我们希望组件中的所有类是不能拆分的，即不应该出现别人只需依赖它的某几个类而不需要其他类的情况。否则，我们后续就好浪费不少时间与精力来做不必要的组件部署。
        CRP原则实际上是ISP原则（接口隔离）的一个普适版。ISP原则是建议我们不要依赖带有不需要函数的类，而CRP原则则是建议我们不要依赖带有不需要的类的组件。

四、总结

         组件构建的三个基本原则为我们描述了一个复杂的决策过程。在决定将哪些类归为同一个组件时，必须要考虑到研发性与复用性之间的矛盾，并根据应用程序的需要来平衡这两个矛盾，这是一件很不容易的事情。组件构成安排应随着项目重心的不同，以及研发性与复用性的不同而不断演化。
        在项目初期，我们更关心项目的可维护性，推进项目进度；在项目后期，关注点则更偏向可复用性。