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.
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?
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.
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.
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.
Subscribe
Twitter
Search
About
Comments
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.
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)
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.
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.
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.
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.
Could someone please link what the other choices are. Just a link, that all i need.
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.
"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.