Thursday, 8 October 2015

Design Principles: Fan-In vs Fan-Out

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

The fan-out of a module is the number of its immediately subordinate modules.  As a rule of thumb, the optimum fan-out is seven, plus or minus 2.  This rule of thumb is based on the psychological study conducted by George Miller during which he determined that the human mind has difficulty dealing with more than seven things at once.

The fan-in of a module is the number of its immediately superordinate (i.e., parent or boss) modules.  The designer should strive for high fan-in at the lower levels of the hierarchy.  This simply means that normally there are common low-level functions that exist that should be identified and made into common modules to reduce redundant code and increase maintainability.  High fan-in can also increase portability if, for example, all I/O handling is done in common modules.

Object-Oriented Considerations

In object-oriented systems, fan-in and fan-out relate to interactions between objects.  In object-oriented design, high fan-in generally contributes to a better design of the overall system.  High fan-in shows that an object is being used extensively by other objects, and is indicative of re-use.

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.

Strengths of Fan-In

High fan-in reduces redundancy in coding.  It also makes maintenance easier.  Modules developed for fan-in must have good cohesion, preferably functional. Each interface to a fan-in module must have the same number and types of parameters.

Designing Modules That Consider Fan-In/Fan-Out

The designer should strive for software structure with moderate fan-out in the upper levels of the hierarchy and high fan-in in the lower levels of the hierarchy. Some examples of common modules which result in high fan-in are: I/O modules, edit modules, modules simulating a high level command (such as calculating the number of days between two dates).

Use factoring to solve the problem of excessive fan-out.  Create an intermediate module to factor out modules with strong cohesion and loose coupling. 










In the example, fan-out is reduced by creating a module X to reduce the number of modules invoked directly by Z.

No comments:

Post a Comment