This introduces a little pattern I discovered the other day, to enhance encapsulation around safe resource access. Maybe we have some resource which we want to apply Resource Acquisition is Initialization (RAII) to. For any readers not familiar with RAII that may be something like an open file, or a mutex or some other resource for which we care about it being released by the program once the program has finished accessing it. It order to manage this in C++ we typically create a class type which acquires the resource in its constructor, allows access to the acquired resource via public methods and releases the resource in the destructor. The C++ language guarantees that the destructor of such an object will be called when its enclosing scope terminates. class RAIIType { RAIIType(int param1, int param2, const char* param3) : resource(nullptr) { // Call external library function to access resource. resource = acquireTheResource(param1, param2, param3); } ...
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...