设计原则高扇入与高扇出答案

【问题标题】：Design Principle High Fan in vs High Fan out设计原则高扇入与高扇出
【发布时间】：2010-11-03 22:28:02
【问题描述】：

谁能用一个例子向我解释一下？我自己越来越矛盾了

两者似乎都自相矛盾。任何人都可以用一个例子来解释它吗？可以在 .NET 框架中使用。

【问题讨论】：

这些术语来自电子：Fan-In 是芯片具有的输入的数量，Fan-Out 是它可以（并行、同时）的设备数量驱动或输出到。例如，一个电灯开关可能有一个输入（电源）并且可以驱动许多灯泡（低扇入，高扇出）。对我来说，一个类调用另一个类以从中获取 inputs（我会称之为 fan-in，但也许我遗漏了一些东西......）并被称为由其他类需要输入时。但是一个类也可以调用另一个类来使某些事情发生。换句话说，这个类比是紧张和误导的。

【解决方案1】：

高扇入是低级课程的好规则。它们应该可以被更高级别的类高度重用。高扇出是高级课程的好规则。他们不应该“重新发明轮子”，而是使用已经存在的代码——在低级类中找到。

所以规则并不矛盾，因为它们涉及不同的类。

【讨论】：

【解决方案2】：

真正有问题的情况是当您同时具有高扇入和高扇出时：

低扇入，低扇出：在任一方向上几乎没有依赖关系的模块。一切顺利。
高扇入，低扇出：一个被高度依赖的模块，但它本身并不依赖太多。就像一个低级实用程序库。
低扇入，高扇出：一个模块依赖于许多其他模块，但也有一些模块依赖它。您确实无法避免使用一个顶级模块将您的整个应用程序捆绑在一起，自然地，该模块将依赖于系统中的每个其他模块。
高扇入，高扇出：一个非常有问题的模块，只要其众多依赖项中的一个发生更改，就会破坏/需要更改，进而破坏系统中依赖的许多其他部分就可以了。

【讨论】：

“自然地，这个模块将依赖于系统中的每个其他模块” 传递性，是的，但这并没有说太多。我们在这里谈论的是直接依赖关系。
@YvesgereY 完全正确。在大型软件程序中，任何单个模块的高扇入和高扇出都不好。有趣的是，有些人认为高扇入或扇出是好的，只要相反的低。事实并非如此。一个结构良好的程序不应该对任何给定的模块有任何非常高的扇入或扇出

【解决方案3】：

您在哪里阅读了高扇出原理？ AFAIK，高扇出很糟糕。

当一个对象必须直接处理大量其他对象时，表示面向对象设计中的高扇出。这表明了高度的阶级相互依赖。一般来说，对象的扇出越高，整体系统设计就越差。

在Code Complete 中也提到，High Fan In with Low Fan Out 是很好的类设计。

【讨论】：

【解决方案4】：

同意@Jeanno。高扇出是不可取的。

“模块的扇出是来自该模块的调用次数。至少三项研究得出结论，扇出平方是与缺陷概率密切相关的设计指标的一个组成部分。” Grady, RB，“成功应用软件指标”，《计算机》，第 27 卷，第 9 期，第 18-25 页，1994 年 9 月 doi: 10.1109/2.312034

【讨论】：

【解决方案5】：

从史蒂夫·麦康奈尔（Steve McConnell）的《代码完成》一书中，您需要高扇入和中低扇出：

高扇入是指有大量类使用给定的班级。高扇入意味着系统已被设计为充分利用系统中较低级别的实用程序类

所以，高扇入是好的，因为这个类被大量使用。可以使用一个类的类越多，这个类就越好。

中低扇出意味着让给定的类使用其他类别的中低数量。高扇出（大约 7 个以上）表明一个类使用了大量其他类，因此可能过于复杂。

另一方面，扇出是类调用了多少东西。我不认为高扇出是真正可取的。是的，您希望您的高级类使用本身是高扇入的低级实用程序类，但是如果您从一个类中调用其中的许多类，您可能会将调用类分解为更小、更简单的部分。这样一来，每个部分都可以通过只调用它们需要的少数实用程序类来实现中低扇出。

【讨论】：