OdeToCode IC Logo

Rise and Fall of Classic OOP

Wednesday, October 5, 2011

When I was making the switch from C and assembly to C++ I did quite a bit of reading on object oriented programming. It's hard to find material on OOP that doesn't praise the classical pillars of encapsulation, inheritance, and polymorphism. In the early years these three pillars were advertised as solution to all the ills of software development. Object oriented programming was my first "silver bullet" experience in the software industry.

Dr. Brumble's OOP Elixir!

OOP has been successful. The majority of the today's most popular programming languages support classical OOP techniques as first class language features. The techniques have even pushed their way into languages like Perl and PHP, and developers including myself have used OOP to build frameworks, applications, and libraries for desktops, devices, and the web.

So then, why did I recently debate an old friend about the decline of OOP?

The Application Framework Mirage

My friend is die hard OOP proponent. He recognizes some of the flaws in the classical OOP principle of inheritance, but for him OOP is the hammer for every nail. He proposed that the most successful UI frameworks he's ever used are all built using classic OOP principles, and therefore objects afford the most modular, reusable, and extensible software possible.

I had some time to think about this argument on a recent flight to Norway, and I think holding up frameworks like Swing and Silverlight (or to go back in time, MFC and OWL) isn't fair. You can always find places where a certain paradigm is the best solution, and for application frameworks in general, and UI frameworks in particular, OOP might have found a sweet spot. A sweet spot because UI frameworks represent an alternate reality. The architects and developers get to make the rules of the reality, and implement the code. Where else but in a UI framework can you find a workable inheritance hierarchy 9 layers deep?

It's not that UI frameworks don't face constraints. There are performance constraints, memory constraints, video constraints. Still, UI frameworks are far away from the messy (and sometimes absurd) realities of the physical world. It is the application code where IS-A relationships are difficult to find and break down quickly. It is application code where roles and responsibilities are difficult to classify and harden into code because domain knowledge can span decades and domain experts will evolve the rules with every passing fiscal quarter.

It's in application code where I've found, over the last few years, that modularization and reuse come about easier by going very big, or going very small. Big in the form of web services, where you can hide an entire platform behind well defined interfaces and standards. Small in the form of functions with well defined meanings, clean inputs and outputs, and nothing but a black box in-between.

Services, classes, functions!

Classes? They get stuck in the middle. There is no generally accepted standard even within a single programming language like C# on how to approach class design, or how to consume a class. Do I inherit from it? Create it with the constructor? Use a factory methods? Use a factory object? Call into the base class method override before I do my work? Or After? Too many choices make simple chores complicated.

To You, My Friend

Look again at the list of the most popular programming languages and see how many languages support more than a single paradigm. It's not that OOP has failed, or is failing. It's just easy to see the other choices now that the silver has worn off the bullet.

Gravatar zvolkov Wednesday, October 5, 2011
Yeah, I've come to same conclusion lately. BTW Eric Raymond said very similar things in his Art Of Unix Programming, written back in 2003! What I think though, is OOP still a useful technique for organizing your logic, just don't try to model your classes after any real-world concepts / entities. I use IoC/DI as my main guiding principle, and my classes model my Software Application Domain, not my Business Domain.
Andrew Wednesday, October 5, 2011
As someone actively working to try to improve my programming abilities in a mostly OOP world, I find myself struggling with the inadequacies you describe.
In a class room writing a class to describe "Employee" and then "Manager" is all well and good, but when you're in the real world and you have to come up with a solution that involves these service level items, that's when the rubber meets the road and makes it's really difficult.
Gravatar Eber Irigoyen Wednesday, October 5, 2011
There are no hard rules (silver bullet) in software develoment, it always depends on the context, with C# though (for example) they have done an amazing job at integrating a bunch of paradigms into the language, so you can use the same language in so many different ways, given you actually have the knowledge to do so, more options, more power and more responsibility.

One thing I tell people is that I don't like being a purist, I like reading what purists do (on TDD and related things for example), just so I know that I don't want to get that far, for me purists are making the mistake of thinking that their paradigm/technology/pattern is a silver bullet, and for me there is no such thing, in software development there are always exceptions (pun intented)
Gravatar tobi Wednesday, October 5, 2011
I found it to be a good technique to let the correctness of the domain organisation slip a bit during normal work, and only periodically do heavy-duty cleanup/refactorings. That way you can defer all major decision to a point where your understanding of the domain (both business and software) is complete. The effort needed for these refactorings amortizes well over all the other efforts.
Gravatar victor Wednesday, October 5, 2011

my thought lately. thanks for saying that. i came to a similar conclusion: classes should be used to help organize our code and not model objects from the real world.
Gravatar David Elyk Wednesday, October 5, 2011
OOP is merely a tool, one of many of which a developer should possess.

The litmus test I use in evaluating languages/frameworks/techniques is does it allow you to do something that is impossible if you didn’t use it? Or allow you to do something that would be very difficult if you didn’t use it, or make something that was previously quite difficult a whole lot easier.
The second measure I use is does it make your code more maintainable and easier to extend/update?

Classes increase code reuse. Polymorphism isn’t required everywhere, but can perform miraculous things. Inheritance and Interfaces as well.

Funny thing happened after I learned OOP. I started writing better procedural code. I worried about separating my data from my code. I learned how to fake OO techniques by writing better functions and treating data more as a separate structure that could be manipulated by different functions that could be bundled in a package together.

Once you learn all these nifty things it’s hard to put them back in the box and forget about them.
Gravatar Ilia Jerebtsov Thursday, October 6, 2011
The "model things as in the real world" is a very powerful paradigm. It makes your code constructs more solid, makes them into well-delimited machines that you can fit in your head and visualize, almost as if they were mechanical. Raise your hand if you thought at one point that a visual designer for OOP classes is a great idea.

It feels like a silver bullet because if you look at it from far away enough, it seems like it can do everything. When you're trying to do something, the intuitive mental model tends to map to classes quite easily.

The problem is when you get up close and it becomes a different thing depending on what direction you look at it from. A class could be a business entity, it could be a service, it could be a component, it could be a representation of an UI widget... All of these things are entirely different paradigms, with entirely different implementation patterns, yet OOP, in it's essence, makes no distinction between them.

You have to figure that out yourself, and before you learn with your own mistakes that there's this whole other layer of patterns and practices you have to learn before OOP becomes truly useful, it will confound you in a subtle and frustrating way.

I think the most profound realization I've had about code is that the machine doesn't care what the code looks like. We try to make understandable code not because it has to be that way for the machine to run it well, but because we, the humans, need to be able to understand what the machine is going to do.

The best paradigm is the one which most easily explains what we're trying to do.
Gravatar Andreas Hartmetz Thursday, October 6, 2011
I think that operating systems are another area where OOP applies well. The Linux kernel does it without language support. I think it would be even better with language support, i.e. C++, probably without exceptions and maybe without runtime type information. Using C++ would encourage putting all modular parts in their own classes, even where it isn't done currently. In my experience, classes tend to be more self-documenting (i.e. understandable without documentation) than a web of functions. And Linux, while mostly well structured, isn't very well documented.
Bryant Thursday, October 6, 2011
Is OOP really on the decline or are there less developers who know how to use encapsulation, inheritance, and polymorphism?
magellings Thursday, October 6, 2011
This is why you have a domain layer in your application. The domain classes go there, classes for other purposes (services, UI, data, etc.) go in a separate layer.
Gravatar Dan Howard Friday, October 7, 2011
Not sure what the point of this is at all. The only classic OOP language was SmallTalk which died a miserable death back in the 90's. Nice catch 14 years later though....
Gravatar Nicolas Friday, October 7, 2011
We tend to use OOP everywhere... Because it is the only true way. And people are convinced of it. That the only software modeling/design technique they learn at school.

But do we really always embrace it in pratice?

Think of webapps. The big picture is what? A user flow. User go from page to page (state to state). There is no generalization, no inheritence, no polymorphism in this concept.

Go into deeper details, and each call to the server is a request. A call to a service if you prefer. You call a function and provide it some parameters. You can think of JSON, SOAP and webservice. And if you jump on stateless bandwagon, your services have no state. Pure procedural/functionnal code.

You might provide an item id to the 'getItemDetail' service for example. You can think your item is a real object with some behavior and is part of a class hierarchy. But actually, this is just an id here.

But there is more, from an id, you create/retrieve an item in your "business model". This object has no behavior and just contain data. Eventually it have public getter/setter so field are private so you can fake using encapsulation...

In the end this data is somewhat taken or writen to the DB. Maybe using an ORM. Yes the O of ORM mean object, but this is more technically speaking than conceptually speaking.

Key OOP concepts like encapsulation and mixing data and code are not used.

We have code on one side with services. And data on another side aka the business or object model.

That how many JAVA webapp are made anyway. This is barelly OOP. You use OOP, it feel like OOP... but this is not OOP.

While it is indeed more procedural or functionnal than anything else, thoses that design theses architecture really thing they do OOP. Because they have a few interface here and here, draw some UML diagrams and use and ORM.

If you talk to them procedural programming is for dinosaurs. Lisp is for artificial intelligence research. Functionnal programming is for maths.
Chloe Pajerek Monday, October 10, 2011
Clearly the OOP paradigm is under pressure, some of which are mentioned. Start with databases, where the "table == class" approach is naive and has many problems. The Web, both in its UI and Service incarnations, also fits poorly with the OOP idea, often necessitating layers and layers of "objects", each tuned to the needs of its "home" layer. Inheritance has proven to be problematic, while Interfaces and Composition remain viable. Still it seems likely that OOP will remain relevant for a long time, even though it will not often be applied in its pure form. That's OK. The real world is a messy place!
Dave the Rave Monday, October 10, 2011
It's not that OOP has failed, or is failing. It's just easy to see the other choices now that the silver has worn off the bullet.

Could someone please link what the other choices are. Just a link, that all i need.
Gravatar scott Monday, October 10, 2011
Gravatar zvolkov Wednesday, October 12, 2011
All, it is very easy to say general things like "there's no silver bullet" and "every tool for its job" and "don't fall into extreme". What Scott essentially proposes here is to take it one step further and ask ourselves: what are the specific ways in which we abuse OOP and what are the scenarios where it is very strong, or on the other hand, pointless.

I agree with Scott and Nicolas, that specifically in (simpler) Web Applications, the request/response cycle provides enough structure/boundaries for state and flow management to not REQUIRE OOP. This explains tremendous success of no-OOP languages like PHP (I know they have classes now).

Also, Ilia Jerebtsov makes a great point: until you know a handful of design patterns you may be inclined to think that OOP is good for modeling real-life entities, which it, as Scott also noticed, is pretty weak at.
Gravatar Martin Monday, October 24, 2011
That list is not a list of most popular languages. It is a list of most "popular" searches on search-engines.

"The ratings are based on the number of skilled engineers world-wide, courses and third party vendors. The popular search engines Google, Bing, Yahoo!, Wikipedia, YouTube and Baidu are used to calculate the ratings."

A language that results in very many search hits can for example indicate that the language is hard and not so user friendly so the user has to search for help. The direct opposite to a popular language. So the list is just pseudo statistics that doesn't say much indeed.
Gravatar luis013 Wednesday, November 16, 2011
Object-oriented programming has declined that day by day there are new techniques and applications to develop programs on the PC, each programming language has its rise and its season, then it depends on each person choose what pleases us most
temp Thursday, December 8, 2011
Comments are closed.