A module in a software system, or any system, for that matter, is defined by its func‐ tion and logic. A function is what the module is supposed to do—its business func‐ tionality. The logic is the module’s business logic—how the module implements its business functionality.

In his book, The Philosophy of Software Design, John Ousterhout discusses the notion of modularity and proposes a simple yet powerful visual heuristic for evaluating a module’s design: depth.

Ousterhout proposes to visualize a module as a rectangle, as shown in Figure 14-6. The rectangle’s top edge represents the module’s function, or the complexity of its

public interface. A wider rectangle represents broader functionality, while a narrower one has a more restricted function and thus a simpler public interface. The area of the rectangle represents the module’s logic, or the implementation of its functionality.

Figure 14-6. Deep modules

According to this model, effective modules are deep: a simple public interface encap‐ sulates complex logic. Ineffective modules are shallow: a shallow module’s public interface encapsulates much less complexity than a deep module. Consider the method in the following listing:

int AddTwoNumbers(int a, int b)

{

return a + b;

}

This is the extreme case of a shallow module: the public interface (the method’s signa‐ ture) and its logic (the methods) are exactly the same. Having such a module introdu‐ ces extraneous “moving parts,” and thus, instead of encapsulating complexity, it adds accidental complexity to the overarching system.