Design Principle High Fan in vs High Fan out

Question

Could anyone please explain this to me with an example? I am getting contradicted myself

• High Fan in: A given class designed in such a way that a high number of other classes can easily consume it.
• High Fan out: A class should be using lot of other classes.

Both seem mutually contradictory. Can anyone explain it with an example using .NET framework if possible?

Answer 1

High Fan In is good rule for low level classes. They should be highly reusable by higher level classes. High Fan Out is good rule for high level classes. They should not "reinvent the wheel", but use the already existing code - found in low level classes.

So the rules are not contradicting because they relate to different classes.

Answer 2

Where did you read the High Fan Out principle? AFAIK, it is bad with High Fan Out.

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

High fan-out in object-oriented design is indicated when an object must deal directly with a large number of other objects. This is indicative of a high degree of class interdependency. In general, the higher the fan-out of an object, the poorer is the overall system design.

Also mentioned in Code Complete , High Fan In with Low Fan Out are good class designs.

Answer 3

Really the truly problematic case is when you have both high fan-in and high fan-out:

• Low fan-in, low fan-out: a module with little dependencies in either direction. All good.
• High fan-in, low fan-out: a module that's highly depended upon, but itself doesn't depend on much. Like a low-level utility library.
• Low fan-in, hight fan-out: a module that depends on lots of other modules, but a few if any modules depend on it. You really can't avoid having one top-level module to tie your whole application together, and naturally this module will depend on each and every other module in the system.
• High fan-in, hight fan-out: a very problematic module that can break / need changes whenever one of its many dependencies changes, and it'll in turn break many other parts in the system that rely on it.

Answer 4

Agree with @Jeanno. High Fan-Out is undesirable.

"The fanout of a module is the number of calls from that module. At least three studies have concluded that fanout squared is one component of a design metric that correlates well to probability of defect." Grady, RB, "Successfully applying software metrics," in Computer , vol.27, no.9, pp.18-25, Sept. 1994 doi: 10.1109/2.312034

Answer 5

From the book Code Complete, by Steve McConnell, you want High fan-in and Low-to-medium fan-out:

High fan-in refers to having a high number of classes that use a given class. High fan-in implies that a system has been designed to make good use of utility classes at the lower levels in the system

So, high fan-in is good because the class is used a lot. The more classes that can make use of a class, the better class it is.

Low-to-medium fan-out means having a given class use a low-to-medium number of other classes. High fan-out (more than about seven) indicates that a class uses a large number of other classes and may therefore be overly complex.

Fan-out, on the other hand, is how many things the class calls. I don't think high fan-out is ever really desirable. Yes, you want your high-level classes to use lower-level utility classes that are themselves high fan-in, but if you call a lot of them from one class you probably could break the calling class into smaller, less complex parts. That way each part becomes low-to-medium fan out by only calling the few utility classes they need.