The Southern Developer

Dependency inversion does not simplify the design After coming up with the code pattern (for adding compile time mocks/stubs/fakes) described in my previous blog post I started to think about system architecture more broadly. One thing which becomes readily apparent is this dependency inversion stuff can only be to facilitate testing. Once it becomes possible to implement the same testing without writing an interface (and using run-time poly-morph-ism) it becomes obvious that the implementation without the interface is the simpler of the designs. Figure 1 To make this concrete take this simple software design where some Behaviour type requires access to a Storage type. Figure 1 shows this in UML notation. The behaviour type probably implements some business rule and the storage implements the sql query code. The dashed line represents a significant component boundary like a package boundary which is considered significant. Figure 2 Figure 2 shows a typical implementat...

The header is the interface In this post I discuss a light weight pattern for introducing stubbing/mocking/faking and test-ability into C++ programs. The title is stated in contrast to the typically used dependency inversion pattern where a separate class interface is declared and the implementation of that class interface defines the implementation of that interface, a stub/mock/fake implementation of this interface is frequently dependency injected when implementing tests. However when using this pattern, by contrast, virtually the same outcome is achieved by replacing the implementation when compiling the tests. This is possible with C++ code due to the header file already defining the interface to a translation unit separately to the implementation. To demonstrate this pattern I am first off presenting it in its most direct form. To start off we have a header file which defines the system architecture and should be included into the code base virtually everywhere. In a large...