In today's column, we ask ourselves why so many systems that claim to be object-oriented are not congruent with the essential principles, and whether a procedural thinking is suitable for modern software development.
“He’s more machine now than man; twisted and evil ", Ben Kenobi declares in Return of the Jedi and thus expresses in plain text the moral of the story. This view is a recurring theme in our literary works, societies and worldviews. So, too, in programming. A thorough account of the matter is provided by David West in Object Thinking, which inspired this blog post.
The thesis of the book is that the patterns of thought that make up the foundation of object-oriented programming (object thinking) are widely different from those found in procedural programming (computer thinking). Now, it’s important to realize that one's own programming does not become object-oriented simply by coding in a language that markets itself in that way. Our conventional languages have, for political and corporate reasons, chosen not to enforce object thinking. Therefore, it is quite possible to, e.g., write COBOL in Java syntax.
Why bother? It works!
It has been many decades since our profession came to the realization that "it works" is a very low bar. Too low, even in its perfected form: "We cannot find any bugs", for systems of today. The software solutions tackle problems in an ever-changing world and thus need to be able to keep up and adapt at low additional cost.
This problem, maintainability, was the raison d'etre for object-oriented ideas. Software written traditionally, more focused on the solution domain (the machine) than the problem domain (the human), was simply too expensive or risky to update and hence quietly went the way of the dodo. All the societal benefits lost to the deteriorating product-market fit or the missed opportunities for innovation is, however, perhaps the real tragedy.
Okay, so what's the main content?
In short, the transition from computer thinking to object thinking is about ceasing to think in the computer’s terms, in favour of starting from the world around us. An object, for example, is not a data structure with a couple of more or less relevant methods taped to it. It is definitely not an anemic data holder that is manipulated by helpers and handlers through getters and setters. Our objects are representations of real (potentially non-living) entities that we gift life and autonomy in a virtual environment, in which they can communicate, collaborate and display behaviors towards other independent objects.
When one's system begins to adopt this type of thought pattern, many programmers are amazed at how much closer we get to the ideals we all know: Encapsulation, high cohesion, low coupling, SOLID and dozens of others.
Further readings
This blog post was inspired by Object Thinking, which discusses programming through an anthropological lens. The book describes our context—philosophical, historical and cultural—with a special focus on the difference between trying to create better software through better tools and processes in contrast to improving individuals.
The book has inspired a movement that has the vision to develop software free from procedural thought patterns. They call this paradigm Elegant Objects and have, in addition to formulating concrete principles, developed a considerable number of frameworks and libraries as well as a new programming language.
Lastly, Peopleware should be mentioned. The discourse in this blog post is, perhaps unsurprisingly, in its essence more sociological than technological. The book confirms that such is the truth for the majority of problems in our field, which means that effective strategies differ from what we might be accustomed to.