清洁体系结构.“组件原则三位一体”示例

Question

我正在阅读关于“组件原则”部分的清洁建筑。

在此，作者阐述了组件设计的三个原则。我觉得我有点孤立地理解他们。

重用/发布等价原则(REP)

我对此的理解是，要使包可重用，需要有适当的版本跟踪机制(版本、文档等)。

公共闭包原理(CCP)

这一条指出，由于同样的原因而发生变化的类需要捆绑在同一个包中。目标是实现可维护性-> --如果应用程序中的某些内容发生了变化，那么它很可能会在单个包中发生变化(或者只有几个)。

通用复用原理(CRP)

如果用户依赖于包，那么它们应该依赖于包中的所有类。

也就是说，包应该只包含那些一起重用的类。

在经过这些原则之后，作者展示了这些原则的“三位一体”，类似于经典的CAP定理：

​

我对此的理解是，在设计组件时，您只能选择遵循这三个原则中的两个。

这是我不太明白的部分：

1. 我不认为使用REP是唯一的其他原则之一。据我理解，满意的REP意味着实现发布管理机制。我不认为坚持中共和CRP能禁止这一点吗？
2. 如何将CCP和CRP结合起来使用？我认为它们是完全相反的原则。前者规定，类的分组方式应使它们在一起进行更改，而后者则规定，类的分组方式应与它们一起使用。我认为这两个目标是截然相反的，我不知道如何能够一起实现它们。

如果有人帮助揭穿这些原则会很高兴，因为这本书缺乏任何可能的“三合会对”的实际例子，例如REP和CRP，REP和CCP，CCP和REP。

如果有人能提供那些缺失的例子，可能的配对，这将是伟大的！

Answer 1

公共闭包原则：不要在应用程序中制作过于宽泛的组件。

倾向于一起更新的组件应该组合在一起。如果在进行一次更改时，许多组件需要更新，那么组件之间可能存在耦合。随着组件之间耦合程度的增加，由于意外的用例和不完善的文档，组件中产生广泛影响的微小更改的可能性也随之增加。

公共重用原则：不要使应用程序中的组件过于具体。

如果组件的用户需要组件的一部分，则应该包含组件的所有部分(因为它们是相关的/需要的)。从用户的角度来看，组件应该做好一件事。构成“一件事”的所有逻辑都应该包含在组件中。将逻辑封装到组件中的主要好处是提高可用性和可维护性，重用单元应该是可重用的单元。

重用/发布等价原则：不要假设组件是完美的。

手动传递单个类是不可维护的。为了使给定的组件有用，必须有一种机制来提供长期稳定性(例如:注意到的固定问题，等等)。因此，应该有某种形式的发布流，可以记录问题，可以找到并使用组件的更新版本。

在从可用性和可维护性的角度确定给定组件的具体/广泛程度时，需要考虑权衡。

1. 中共没被跟踪？组件无法维护。很难解决问题/添加增强。
2. CRP没有被跟踪？组件是没用的。很难使用组件。
3. 代表没被跟踪？组件不能被信任。很难使用组件。

有一些权衡，但与CAP相比似乎有点牵强。上限更像是“挑选你的毒药”，而这更像是“记住为什么要编写组件”。我倾向于认为存在一些主观的最优结构，它提供了可用和可信赖的组件。帽状态客观上只能选择2种。