Response to the flaws in the SOLID principles

http://codeofrob.com/entries/my-relationship-with-solid---starting-with-s.html

Because I hate the comment system on his blog... here is my response to the above post.

The massive flaw in all this is the semantics. The "Horizontal" and "Vertical" seperation is, not only a simplistic set of terms from the business world, but useless semantics that do not map to anything execept your own weird two dimensional internal mental model. There are no intrinsic "dimensions" to a codebase that would support you using these as axiomatic semantics, that other folk would "grok" automatically. We deal in abstractions, don't fall into the habit of trying to map high order abstractions back to simple and limiting lesser systems that impose non-existant contraints. its quite possible to flatten everything onto a whiteboard board but thats not the reality. Any non-trivial codebase has a multi-dimensional graph of relationships, dependencies and states that cannot be simply represented in a 2d image.

This is not to say that I disagree with your intent. If you observe your naming conventions, you will see that your "horizontal" model could equally be called a "Functional" model as it uses very "functional" descriptors for the names of the entities it is describing, while your "vertical" model shows a naming convention very similar to a "logical" description of the entites its describing. The fun part comes when you realise that a single class can have a single functional description, but may have multiple logical descriptions and vice versa.

The problem, once we have established my proposed naming convention, is that every class and interface has a dual role within the architecture. Let's take for example the "controller" class. Which functionally performs a "control" function of some resource or process; while logically it may be part of a business rule that manages a transaction. How do we reconcile these dual identities in both the naming conventions and the "architecture" decisions?

Once you identify this duality, its easy to start to see how concepts like SOLID are one-eyed and only allow you to see one or the other role at a time. Which ends up with both roles being mixed through the codebase names, comments and relationships.

We need a better system to conceptualise the roles and functions of the design entities that can capture the actual complexity rather than ignoring half of it and hoping it goes away.