OO ... worth the pain?
I have often wondered whether the quest for pure object oriented (OO) solutions is worth the pain and suffering most of these projects have to endure, from the issues of getting to grips and onto a common thread with pattern enthusiasts, tying the knot between an OO solution and a relational database, to debugging and wrapping up a solution tied together with functoids, aggregation, facades, inversion of control and other terminology that most ... or some .. of us recognise. I have been involved in solution design and development since the early 80's and tripped across OO in the mid 80's for the 1st time. My mentor at the time was on a quest of OO perfection and solutions were completed on time, according to blueprint and were a joy to maintain. These days ... a mere 20 odd years later ... I often get entrenched in solutions based on OO principles, patterns, frameworks and other goodies, yet they are a mission to digest and understand, not to mention the complexity and cost of maintenance.
Is OO really intuitive ... is OO really adding value ... is OO simply a way of IT technologist abstracting a simple business solution from the user and shrouding it in mystery? Looking at the 80's solutions my answer would be no. Looking at today, the answer is a definite yes and my concerns are shared by fellow colleagues and most of the IT people we get exposed to as part of the developer readiness program.
So is OO bad?
Most definitely not, instead we should be more concerned about TLA's (three lettered acronyms) which are creating more chaos and confusion in the industry than anything else, least of which OO ... sorry object orientation. The key is to keep the solution simple, implement what is needed today and add what is needed in the future when and as it is required. Trying to forecast the future of any solution requires a crystal ball that none of us have been able to find and complicates the solution without any real effort. Just as OO, patterns are an ingenious concept and must be considered, however, avoid flooding project members with this and that, or rather that, if not we could consider that and/or that pattern ... successful solutions are those that give all involved a sense of achievement and "comfort", making it a maintainable solution ... rather than confusing team members before the real complexities of solutions even emerge.
If we realise that OO is merely another tool in our toolbox and that solutions should remain to be simple and intuitive, then the success my first mentor demonstrated with each solution he tackled, will accompany us as well.