设计原则高风扇与高风扇输出

Question

有人可以用一个例子向我解释一下吗？我自相矛盾

• High Fan in：一个给定的类，其设计方式使得大量其他类可以轻松使用它。
• 高扇出：一堂课应该使用很多其他课程。

两者似乎都是自相矛盾的。可以用一个例子解释一下吗？可以在.NET框架中使用。

Answer 1

High Fan In是低级别课程的理想规则。它们应该由更高级别的课程高度重复使用。高扇出是高等级的好规则。他们不应该“重新发明轮子”，而是使用现有的代码 - 在低级别的类中找到。

所以规则并不矛盾，因为它们与不同的阶级有关。

Answer 2

你在哪里读过高扇出原理？ AFAIK，High Fan Out很糟糕。

http://it.toolbox.com/blogs/enterprise-solutions/design-principles-fanin-vs-fanout-16088

  

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

在Code Complete中也提到过，低扇出的高扇出是优秀的设计。

Answer 3

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

＆＃34;模块的扇出是来自该模块的呼叫数。至少有三项研究得出结论，扇出平方是设计指标的一个组成部分，与缺陷概率很好地相关。＆＃34; Grady，R.B。，＆＃34;成功应用软件指标，＆＃34;计算机，第27卷，第9期，第18-25页，1994年9月 doi：10.1109 / 2.312034

Answer 4

真正有问题的情况是当你同时拥有高扇出和高扇出时：

• 低扇入，低扇出：一个在任一方向上几乎没有依赖关系的模块。一切都好。
• 高扇入，低扇出：一个高度依赖的模块，但本身并不依赖于它。就像一个低级实用程序库。
• 低扇入，高扇出：依赖于许多其他模块的模块，但有一些模块依赖于它。你真的无法避免让一个顶层模块将整个应用程序绑定在一起，当然这个模块将依赖于系统中的每个其他模块。
• 高扇入，高度扇出：一个非常有问题的模块，无论何时其中一个依赖项发生变化，它都可以破坏/需要更改，并且它会反过来打破其中的许多其他部分依赖它的系统。