March 14, 2016

...Learn TDD with Codemanship

Composability - The Real Goal of S.O.L.I.D.

A brief note on the topic of composability and OO design principles...

When we look at our S.O.L.I.D. principles, we can see - if we choose to - that their ultimate end goal is to give us to ability to change and adapt our software by re-composing the different parts, swapping out one object with another that, for the outside, looks the same and behaves in a way that's compatible with the original.

Take this high level design for a stock trading application:

By splitting the work up into separate modules, each of which has a specific responsibility, and then wiring the different modules into the application using dependency injection - binding the Application class to abstractions - we buy ourselves the ability to achieve many combinations of app logic with different user interfaces, different reporting outputs, different databases for persistence and using different external sources of stock price data.

e.g., we could have a Windows UI, outputting reports to Excel, storing the data in a Neo4J database, and getting our stock prices from Bloomberg. There are actually 3x3x3x3 possible combinations of these different modules, all - if we've observed the Liskov Substitution Principle - totally valid and working.

So, from 13 implementation modules (including the Application class), we can squeeze out 81 possible systems. All we have to do is write a line or two of code to wire the components together:

Notice, also, how this pattern is repeated - Mandelbrot-style - for the implementation of the Excel output. It, too, has options: here we choose to use the JdbcWriter to actually write the Excel files. A different writer implementation might automated MS Excel itself through the API. And so on.

Conversely, if we'd designed our Application like this:

Then the system would offer us only one possible easily accessible configuration. We'd need a different Application class for every desired configuration.

Doing it the S.O.L.I.D. way, our configured system is wired together, injecting objects into objects that in turn get injected into other objects - rather in the style of Russian dolls - from the top of the call stack. A web version of this system might wire together a different combination in the start-up script.

And adding new implementation modules (e.g., a Crystal Reports output) is a doddle, because the rest of the system just sees that Output interface and expects generic Output behaviour.

I thought I should mention it, because composability is all too often overlooked as the real goal of S.O.L.I.D.

Posted 1 year, 8 months ago on March 14, 2016