What?? Object-oriented programming (OOP) is practically the standard in software! It’s taught everywhere and dominates thinking on the subject. Most languages are O-O these days, and OO features have even been added to COBOL! How can such a dominant, mainstream thing be bad?
The sad truth is that the badness of OOP isn’t some fringe conspiracy theory. An amazing line-up of astute, brilliant people agree that it’s bad. A huge collection of tools and techniques have been developed and taught to help people overcome its difficulties, which nonetheless persist. Its claims of virtue are laughable – anyone with experience knows the benefits simply aren’t there.
Object-oriented languages and novels
Object-orientation is one of those abstruse concepts that makes no sense to outsiders and is a challenge for people learning to program to understand and apply. To make OOP monstrosity clear, let’s apply OOP thinking to writing a novel.
There are lots of ways of writing novels, each of them suitable for different purposes. There are novels dominated by the omniscient voice of the author. There are others that are highly action-based. Others have loads of dialog. Of course most novels mix these methods as appropriate.
Some novels feature short chapters, each of which describes events from a particular character’s point of view. There aren’t many novels like this, but when you want to strongly convey the contrast between the contrasting experiencing of the characters, it’s a reasonable technique to use, at least for a few chapters.
What if this were the ONLY way you were allowed to write a novel??!! What if a wide variety of work-arounds were developed to enable a writer to write -- exclusively! -- with this sometimes-effective but horribly constricting set of rules?
What if ... the Word Processors (like Microsoft Word) from major vendors were modified so that they literally wouldn't allow you to write in any other way, instead of giving you the freedom to construct your chapters any way you wanted, with single-person-point-of-view as one of many options. What if each single small deviation from that discipline that you tried to include were literally not allowed by the Word Processor itself!? All this because the powerful authorities of novel creation had decided that single-person chapters were the only good way to write novels, and that novelists couldn't be trusted with tools that would allow them to "make mistakes," i.e., deviate from the standard.
There would be a revolution. Alternative publishing houses would spring up to publish the great novels that didn’t conform to the object-novel constraints. The unconstrained books would sell like crazy, the OO-only publishing houses would try to get legislation passed outlawing the unconstrained style of writing, and after some hub-bub, things would go back to normal. Authors would exercise their creative powers to express stories in the most effective ways, using one or several techniques as made sense. The language itself would not be limited or limiting in any way.
Sadly, the world of software works in a very different way. No one sees the byzantine mess under the “hood” of the software you use. No one knows that it could have been built in a tiny fraction of the time and money that was spent. Industry insiders just accept the systematized dysfunction as the way things are.
This is objects – a special programming technique with narrow sensible application that has been exalted as the only way to do good programming, and whose rules are enforced by specialized languages only capable of working in that constrained way.
Is there nothing good about OOP?
It isn’t that OOP is useless. The concept makes sense for certain software problems – just as completely other, non-OOP concepts make sense for other software problems! A good programmer has broad knowledge and flexible concepts about data, instructions and how they can be arranged. You fit the solution to the problem and evolve as your understanding of the problem grows, rather than starting with a one-size-fits-all template and jamming it on. You would almost never have good reason to write a whole program in OO mode. Only the parts of it for which the paradigm made sense.
For example, it makes sense to store all the login and security information about a body of software in a single place and to have a dedicated set of procedures that are the only ones to access and make changes. This is pure object-orientation – only the object’s methods access the data. But writing the whole program in this way? You're doing nothing but conforming to an ideology that makes work and helps nothing.
However. When you embody OOP in a language as the exclusive way of relating data and code, you’re screwed.
In this post I describe the sensible origins of object-orientation for describing physical simulation, for example for ships in a harbor. Having a whole language to do it was overkill – I describe in the post how hard-coding the simulation in statements in a language made it hard to extend and modify instead of moving the model description into easily editable metadata -- and then into a provably best optimization model..
That is the core problem with object-oriented languages – they are a hard-coded solution to part of a programming problem, rather than one which creates the most efficient and effective relationships between instructions and data and then increasingly moves up the mountain of abstraction, each step making the metadata model more powerful and easier to change. Object-oriented concepts are highly valuable in most metadata models, with things like inheritance (even multiple inheritance, children able to override an inherited value, etc.) playing a valuable role. Keeping all the knowledge you have about a thing in one place and using inheritance to eliminate all redundancy from the expression of that knowledge is incredibly valuable, and has none of the makes-things-harder side effects you suffer when the object-orientation is hard-coded in a language. In the case of simulation, for example, the ultimate solution is optimization – getting to optimization from object-oriented simulation is a loooong path, and the OOP hard-coding will most likely prevent you from even making progress, much less getting there.
Conclusion
Any reasonable programmer should be familiar with the concepts of encapsulation, inheritance and the other features of object-oriented languages. Any reasonable programmer can use those concepts and implement them to the extent that it makes sense, using any powerful procedural language, whether in the program itself or (usually better) the associated metadata. But to enforce that all programs be written exclusively according to those concepts by embedding the concepts in the programming language itself is insanity. It's as bad as requiring that people wear ice skates, all the time and every day, because ice skates help you move well on ice when you know how to use them. If everything were ice, maybe. But when you try to run a marathon or even climb a hill with ice skates on, maybe you can do it, but everyone knows that trading the skates for running shoes or hiking boots would be better. Except in the esoteric world of software, where Experts with blinders on declare that ice skates are the universal best solution.
Comments