Принцип дизайна Высокий Вентилятор в сравнении с Высоким Вентилятором

Question

Может ли кто-нибудь объяснить это мне на примере? Я противоречу себе

• High Fan in: данный класс разработан таким образом, что его может легко потреблять большое количество других классов.
• High Fan out: класс должен использовать много других классов.

Оба кажутся противоречивыми. Кто-нибудь может объяснить это на примере? возможно в .NET Framework.

Answer 1

High Fan In - хорошее правило для классов низкого уровня. Они должны быть многократно использованы классами более высокого уровня. High Fan Out - хорошее правило для классов высокого уровня. Они не должны «изобретать велосипед», а использовать уже существующий код, который можно найти в классах низкого уровня.

Так что правила не противоречат, потому что они относятся к разным классам.

Answer 2

Где вы прочитали принцип High Fan Out? AFAIK, это плохо с High Fan Out.

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

Сильное разветвление в объектно-ориентированном проектировании указывается, когда объект должен иметь дело непосредственно с большим количеством других объектов. Это свидетельствует о высокой степени взаимозависимости классов. В целом, чем выше разветвление объекта, тем хуже общий дизайн системы.

Также упоминается в Код завершения , High Fan In с Low Fan Out - это дизайн хорошего класса.

Answer 3

Действительно по-настоящему проблемный случай, когда у вас есть как высокий, так и большой разветвления:

• Низкий уровень вентилятора, низкий уровень вентилятора: модуль с небольшими зависимостями в любом направлении. Все хорошо.
• Высокий уровень вентилятора, низкий уровень вентилятора: модуль, от которого сильно зависит, но который сам по себе не сильно зависит. Как низкоуровневая служебная библиотека.
• Низкий разветвленность, повышенный разветвленность: модуль, который зависит от множества других модулей, но от него зависит лишь несколько модулей. Вы действительно не можете избежать одного модуля верхнего уровня, чтобы связать все ваше приложение вместе, и, естественно, этот модуль будет зависеть от каждого модуля в системе.
• Большой разветвленность, высокая разветвленность: очень проблемный модуль, который может ломать / нуждаться в изменениях всякий раз, когда меняется одна из его многочисленных зависимостей, и, в свою очередь, ломает многие другие части в системе которые полагаются на это.

Answer 4

Согласен с @Jeanno.Большое разветвление нежелательно.

"Разветвление модуля - это количество вызовов от этого модуля. По крайней мере три исследования пришли к выводу, что квадрат разветвления является одним из компонентов метрики проектирования, которая хорошо коррелируетк вероятности дефекта. " Грейди, Р.Б.," Успешное применение метрик программного обеспечения ", в Компьютер, том 27, № 9, с.18-25, сентябрь 1994 г. doi: 10.1109 / 2.312034