kirit.com
Return to Page
While the original article was flawed, I'm not sure it was as flawed as you are making it out to be.
There has been a trend in the industry to bolt “object orientation” onto every programming language “because that's what they want”. The reality is that OO is relevant to specific parts of system design… but it isn't a universal need and in fact gets in the way of solving specific domain problems… problems that are commonly encountered as parts of large systems.
So the “conspiracy theory” really boils down to language designers adding object orientation simply as a checkoff item for marketing, and not as a true value add. Not much of a conspiracy except that in the supposed service of customer demand for a feature, resources are taken away from developing the core strengths of the language.
Looking at a concrete example, I will use a large system I have been working on for the last seven years. Does it use object orientation? Why yes it does… but only where it is appropriate. Now the OO faithful will try to tell you that OO is appropriate everywhere, and the idea of having subsystems that are *wrapped* in OO but are not OO themselves is treason or a sin or some other silly metaphor.
But let's face facts: almost any enterprise system needs to talk to data and almost all data is stored in relational databases these days. Are relational databases OO? Nope. Entire industries have arisen attempting to hammer relations into objects (object-relational databases, object relational mapping, data services layers). These attempts have for the most part been disappointing. I personally use an ORM, but mostly because it wraps the raw data access in a type safe way (which helps avoid late binding bugs) and not because I really *care* about the objects it creates on the domain object level. I still have a business logic layer that creates higher level domain objects to aggregate and control the low level data objects.
Likewise, I need to perform calculations that are user controlled (somewhat akin to a specialized spreadsheet capability). Did I add object orientation to that domain specific language? No I did not, although the systems *interface* to that subsystem is wrapped in objects, the calculation engine is object free. The reason for this is that the users are expecting a spreadsheet like experience, not a hierarchy of objects encapsulating data.
In another area we churn logic rules to resolve the application of a very complex business rule set (created by a complex legal environment we work in). Did I add objects to the logic engine? Nope. Embedded prolog rules express the domain quite clearly without the additional clutter. Again, that subsystem is *wrapped* in objects for access.
At the end of the seven years of development of this system, what I have concluded is that objects are excellent for *structuring* a system. They allow the expression of chunks of code and data that can interact via predefined interfaces. In that regard, object orientation is an excellent solution. However, when I drill down to specific needs, I find myself using specific languages (either off the shelf or custom domain specific languages) and in these cases the problem space has been reduced in a way that objects are a hindrance to the success of the subsystem.
I store my data in relations, because relations have powerful mathematical properties that ensure coherency of data. I store my logic in prolog rules because that rules engine allows concise definitions of the problem space (and backtracking is sufficient to resolve it). I store my calculation engine in a spreadsheet like domain specific language because that is what matches the problem domain and is easily manipulable (via a spreadsheet) by my end users.
What all this means is that, while object orientation was a powerful step forward for *some* problem domains, it is not an panacea. Surely I could store my data in an object-relational database, my logic in logic objects and my calculation engine in calculation objects… but at a high cost in overhead because objects fail to represent the domain space as clearly as the non object solutions do. Yet, language vendors keep tacking objects on, despite the fact that in many cases they provide little or no value to the solutions produced.
In this regard, there is a “conspiracy”. The sad thing is that it created by clueless programmers and their managers who insist that objects are the final solution to all problem domains and thus mandate that all languages they use support them. It is a conspiracy of catering to the lowest common denominator.
John, first of all thank you for your thoughtful comment. I think we are much more in agreement than first glance might suggest.
As I say at the end of The three pillars of Object Orientation I see OO as a great tool to help manage complexity in projects. To borrow Fred Brooks' terms, too many people have tried to apply OO dogmatically to try to solve accidental difficulties and I'm not at all surprised that they have difficulty with that. This misapplication of a good tool for the wrong job is a big problem, but it isn't solved by an equally dogmatic determination to use functional programming everywhere.
When Kirsten Nygaard and Ole-Johan Dahl invented OO for Simula they invented it as a tool for managing the complexity of their simulations. As you have found, this is where OO is most useful. It is the sharpest knife I've found for chopping big complex systems up into manageable chunks.
The OO fan-boys who insist that everything be an object annoy me as much as the functional fan-boys who insist every problem can be solved with higher order functions, recursion and LISP macros. Both sides are right that every problem can be solved in their way, but it doesn't make either the most useful approach. They're both missing the difference between the essential and accidental difficulties that we face.
The only way to help ameliorate this is better education. I see one part of this as slapping dogmatic firebreathers, and unfortunately "Why OO sucks" is dogmatic rubbish in places and in other places confuses personal preference with universal good working practices.
As for the conspiracy, I just don't see it. There is no conspiracy, just market forces. We shouldn't assume that our industry is any less fadish than any other.
There are interesting parallels between OO and Codd's original description of relational systems. Early adoption of relational databases was equally modish to the OO fad in the early/mid nineties and was also equally let down by basic misunderstandings about the point of it and poor implementations that couldn't do the things that were required in order to actually make use of relational databases in the way Codd described them.