Many bytes have been spilled on the topic of object-oriented programming: What is it? Why is it? Is it good? I’m not sure I have the answers to these questions, but I have observed an interesting trend that I think has flown under the radar: OOP is not disappearing, but shifting across domains.
Some quick and entirely incorrect history
In times of old, people wrote programs. Things were easy and simple. Then, a manager that didn’t know how much trouble they were getting themselves into asked two programmers to work on the same program. Bad things happened.
Some bright spark realised that bugs often appeared at the intersection of software functionality, and that it might be a sensible idea to perform a bit of invasive surgery and separate those functions with an interface: an at-least-vaguely specified contract describing the behaviour the two functions might expect from one-another.
Other bright sparks jumped in on the action: what if this separation did not rely on the personal hygiene of the programmers - something that should always be called into question for public health reasons - and was instead enforced by the language? Components might hide their implementation by default and communicate only though a set of public functions, and the language might reject programs that tried to skip around these barricades. How quaint.
Nowadays, we have a myriad of terms for these concepts, and others which followed in an attempt to further propagate the core idea: encapsulation, inheritance, polymorphism. All have the goal of attenuation the information that might travel between components by force. This core idea isn’t unique to OOP, of course, but it is OOP that champions it and flies its coat of arms into battle with fervour.
Programs-as-classes
At around the same time, some bright spark realised that programmers - a population of people not known for good hygiene - might also not produce the most hygienic of programs, and that it was perhaps important not to trust all of the little doo-dahs that ran on your computer. And so the process boundary was born, and operating systems morphed from friendly personal assistants with the goal of doing the dirty work of programs into childminders, whose work mainly consisted of ensuring that those within their care did not accidentally feed one-another snails or paperclips.
In tandem, other bright sparks were discovering that computers could be made to talk to one-another, and that perhaps this might be useful. Now, programs written by people that didn’t even know one-another - let alone trust one-another - could start interacting.
When trust dissolves, societies tends to overzealously establish the highest and thickest walls they can, no matter the cost. Software developers are no different. When every program has evolved into a whirlwind of components created by an army of developers that rarely know of their software’s inclusion, much less communicate about it, then the only reasonable reaction is maximum distrust.
... continue reading