Dependency Inversion and Mocking

Any non-trivial routine or class usually has two type of interfaces the incoming interface and the outgoing interface. The incoming interface is part of the class definition, and therefore well understood. The outgoing interface is not formally defined in the class interface, and it consists of the methods a class calls on other objects. A poor job on the outgoing interface will create poor code, even if the incoming interface is well designed. To avoid this, the code should use dependency inversion.

Dependency Inversion is defined by Robert Martin as

1. High level modules should not depend upon low level modules. Both should depend upon abstractions.
2. Abstractions should not depend upon details. Details should depend on abstractions.

Mocking is a useful technique for helping to achieve dependency inversion.

Much code development starts bottom up, with the definition of small classes with limited scope. The classes are then composed into larger classes. This tends to create kitchen sink classes, with many capabilities, since the needs of high level classes are not really known in advance.

With mocking, you start with with classes that have large scope and start testing the design with interfaces rather than classes. The interfaces can be mocked and left unimplemented until the design is perfected. Only when the design is proven as useful, do you implement the interface in a class. This type of design process ensure that your classes remain lean, because you build them only to fulfill the needs of real clients with known requirements. One danger though, is the proliferation of small classes with small interfaces. Ideally you should aggregate interfaces to create one class that implements several related interfaces.