Coding Horror: Your Code: OOP or POO?
From the comments:
generally, people need to use module-oriented programming, but the lack of support by most mainstream language of the day makes them rely on object-oriented programming instead, calling for all possible abusements.
My own career followed an unusual trajectory. Because of where and when I got my Master’s degree, I was exposed to Ada 83; and because of where and when I worked, I had a chance to actually apply it, before I ever did any C++ programming.
Ada 83 was the first standardized version of the Ada programming language, and it was a curious beast. It’s one of the few examples of the transitional phase in software development, after language designers had learned of the value of modularity and information hiding, but before object-oriented programming set the world on fire. (The only other example that comes to mind is Modula-2, another creation of Pascal’s designer, Niklaus Wirth.)
Pascal — the language from which Ada derived its basic syntax — ruthlessly enforced the principles of structured programming, and taught a generation of comp-sci graduates (including me, class of ‘85) the value of those principles. Ada did the same with modularity and information hiding; data and subroutines were grouped into packages, interface modules controlled interaction between packages, and the visibility of package components could be finely controlled. This appealed to me, as it reinforced the ideas I’d picked up from my senior-year courses in software engineering, using the text Structured Design, by Edward Yourdon and Larry Constantine: maximize cohesion (keep closely related things within the same syntactic unit) and minimize coupling (make sure interactions between units are few in number and explicitly defined).
The idea of all this being to make maintenance easier, by allowing program components to be modified in isolation, without breaking other modules that interacted with them. Unless the modifications resulted in changes in the (narrowly and explicitly defined) interface, changes would not propagate to other modules. (Bertrand Meyer’s “design by contract” principle took this idea further still.) That was the theory, anyway; but practice actually approximated theory, if not perfectly. Modularity is one of the few ideas that everyone (now) agrees is a Good Thing.
All the tools to do modular programming are present in C; you can declare your interfaces in .h files, and keep everything else private using the ’static’ keyword. But typical C programmers of that time didn’t know that one should program that way, and the language design didn’t make it the path of least resistance. (Top-level functions have linkage unless you explicitly say otherwise; the compiler doesn’t disallow referencing declarations in .c files or defining declarations in .h files, no support for namespaces, etc.) So it wasn’t typically done that way. But knowing Ada, and knowing the rationale behind it, made me a better C programmer; my programs followed modular conventions, and strictly controlled visibility. (And when C programming is still done these days, that is the typical practice.)
All of these principles got swept up into the meme-complex known as “object oriented programming”; and since the industry transitioned from the kinda-sorta modular C to the object-oriented C++, without a fully modular language in between, people credited OOP with benefits that weren’t really intrinsic to OOP, but were intrinsic to — for want of a better buzzphrase — module-oriented programming.
OOP was oversold. You had to live through it to get an idea of how intense the hype was. The industry was convinced that non-object programming was evil; that hybrid programming, such as was allowed in C++, made baby angels cry. So one of the design criteria for languages like Java was that everything had to be an object, for better or worse. The basic usefulness of hybrid programming eventually led to the development of the Singleton design pattern and EJB session beans, and other semantic dodges that let programmers escape the ideology in order to get their job done.
As you might guess, I am not too impressed by the object-oriented everything ideology. Inheritance and dynamic binding are useful tools, but organizing your whole tool stack and API around them is a mistake. I prefer languages that allow hybrid programming (like Python, JavaScript, Perl, and C++); though I’ll allow there’s something to be said for languages like Ruby, where the object metaphor is so thoroughly baked in that you can choose to ignore it.
This is another reason I’m intrigued by the Scala programming language; while nominally as thoroughly OOP as Java, the Singleton pattern is baked in; you can just declare an Object, using the same syntax as for declaring a class. The distinction between this and a plain old Module is inconsequential.
I’m hopeful. After nearly twenty years, the industry and the profession seem to be recovering from the “object-oriented everything” mania. It’s about time. I wouldn’t want to do without classes and objects; but I’d rather have more than that hammer to work with, so that I can deal with whatever un-nail-like projects come along.