Well, I obviously don't think so, but Richard Mansfield sure does. He's got an article over at DevX talking about his problems with OOP.
Read the full article at http://www.devx.com/DevX/Article/26776/0/page/1.
While he makes some good points, I think the article, overall, takes the wrong approach - it attacks OOP without understanding what it is. My points of contention start with the first line:
"(OOP) offers benefits only in a specialized context?namely, group programming"
Then why have my personal projects gotten cleaner and more flexible?
"Still trying to get OOP right after ten years? Something strange is going on here."
OOP is hard. Too many people jump to the code without thinking about what the code is really doing: delegating responsibility and defining collaboration.
"That's why very few programming books I've read use OOP techniques (classes, etc.) in their code examples."
Funny, the first programming book I got in college was "Solving Problems with Objects and Data Structures in C++."
"OOP is to writing a program what going through airport security is to flying."
That's bass-ackwards. OOP/OOD/OOA is to writing a program as figuring out what runways are going to handle what planes before telling them all to land.
"In effect, a programmer with no knowledge of the specific inner workings of your encapsulated class is asked to reuse it"
And this is a problem? I seem to remember that this is the point.
"Even after years of OOP, many?perhaps most?people still don't get it."
I think you're probably one of them. Most people don't get discrete math, but successfully apply some of its problem-solving principles daily.
"History has seen these 'final best solutions' many times, when waves of professors applauded some idea"
Get your head of of the academic sand, man. Take a look at what's going on in the industry today - I haven't seen anyone selling OOP as the endgame of programming paradigms. Have you heard of service or component orientation?
"Few people attempt to modify the methods of components. You may change a text box's font size, but you don't change how a text box changes its font size."
Hence why they're called "components." It's a tradeoff, and it's what we're here for.
"This dynamic environment wreaks havoc on your 'nouns' (object classifications). You can find yourself trying to fit things into categories more often than you're actually programming. Sound familiar?"
It's just as easy to design things poorly in OOP as it is in procedural design. Misunderstanding of OOP principles and people's naive love for inheritance (usually caused by never getting past that Inheritance chapter to "Using Composition Instead of Inheritance") all too often causes this "inflation."
However, it's still much easier to create a dynamic, complex application with OOP. OOP, at a base level, compartmentalizes responsibility for data and collaborations. It's a lot easier to swap out an object for one with the same interface than to pour over millions of lines of procedural code, looking for every instance of a given variable name.
"The catch is that in the real world programming jobs rarely are perfect, nor class details flawless."
I haven't met any programmer, OOP or procedural, who thinks they'll get it right the first time.
"Indeed, in Microsoft's Visual Studio .NET suite of languages, the compiled result is identical whether you use Java, C++, or Basic."
And...ummmm...an object-based type system is part of what makes it happen. And that Visual Studio GUI...yeah..objects there, too.
"Programming has become bloated?ten lines of code are now needed where one used to suffice."
That's backwards again, and a gross simplification. Those ten lines should be reusable over...and over...and over...and when something changes, you only change in one place.
"Massive API code libraries are "organized" into often-inexplicable structures, requiring programmers to waste time just figuring out where a function (method) is located and how to employ it."
Funny...I just moved from a Java based platform to .NET, and everything seems to be in logical places. System.Data...hey...that's where I find my data layer! Imagine that!
Anyhow, I need to go to the gym.
7 comments - Posted by Joe Rinehart at 8:33 AM - Categories: ColdFusion MX