Object Oriented Programming Oversold (2001)

http://web.archive.org/web/20010310074457/http://www.geocities.com/tablizer/oopbad.htm

by blowski • 11 years ago

40 52 11 years ago

web.archive.org

exDM692• 11 years ago

Random quote from the article:

I will eat a week's pay if OOP is still in vogue in 2015.

So, is it time to make the OP eat a week's pay or not? I'd say no.

troels3• 11 years ago

I'd say yes. Pony up.

Udik• 11 years ago

Most of the "OOP" code I've seen recently is made mainly of static functions organized in classes with little or no state, instantiated and injected by a DI container in the name of flexibility. So I'd say that, in some sense, it's much less in vogue than it was fifteen years ago.

w0utert• 11 years ago

I'd say yes. Even though I agree with many of the points the article makes, OOP is still very pervasive, and I'm pretty sure it's still by far the most used development paradigm for most types of software. OOP may not be ideal or perfect, but OOP languages can be used to shoehorn almost any kind of problem into, which is exactly what people are still doing today. Often times producing a terrible mess that hardly works, but that's besides the point for his challenge ;-)

Anyway, he makes many valid points, like other articles about the disadvantages of OOP, but none of these every draws any convincing conclusions why OOP is 'bad' and why something else would be 'better'. In programming there is no paradigm that fits every application, OOP is just one of many ways to solve problems, and one that has proven that (if used pragmatically) works very well for a very broad range of problems.

exDM692• 11 years ago

Yes, I'm going to have to agree with this. OOP is just one paradigm.

But what has changed from the years this article was written is that OOP is not touted a panacea. Back when I learned to code, OOP was a synonym for "good".

That's why I'm saying no. OOP is no longer the hyped as it once was.

svdree• 11 years ago

I like the "split ends" analogy. A lot of developers seem to worry too much about issues that aren't actual problems, other than that something is "not OO".

An actual example of this I saw recently, was when I got into an argument with someone over the use of standalone functions in C++. Apparently, these are evil, and functions should always be part of a class.

Of course, a class with only static functions is basically a namespace. No problem, apparently statics are also evil. So let's not make these functions static, even though they're not accessing any member data.

But now, when we want to use these functions, we need to instantiate an object, which is a bit silly. No problem, we'll just make it a singleton.

I shit you not, this actually happened.

JustSomeNobody2• 11 years ago

Once, I was using a struct for some simple data. I added a very simple member function to sanely format the data. I thought I was going to be hung in the code review for not using a "proper" class.

troels3• 11 years ago

Singleton? No no, those are ALSO evil. No, we need to use a dependency injection container to provide that object instance.

troels3• 11 years ago

Funny anecdote: I was recently contracting at a company that was OOP gone amuck. Everything written in Java ca. 2001 style. Lot's of message wrapping and unwrapping. Lots of dependency injection fun and games.

At some point, their lead developer tells me about some guy they had for a job interview a while back, and as the story goes they had him through a code review where he was berated for using a static helper class. Apparently his reply was something like "You're using static classes for view helpers? But that's insane!". The morale of the story as told, was that clearly he didn't know right from wrong and was passed over. I didn't know what to reply to that.

arethuza4• 11 years ago

"Java ca. 2001 style" also seemed to include using every feature of J2EE even if it wasn't remotely relevant.

Crazy files of constants seemed to feature a lot as well:

   public final static string HTTP = "HTTP";
   public final static string COLON = ":";
   public final static string SLASH = "/";

and then the inevitable:

   string url = HTTP + COLON + SLASH + SLASH....;

[I did think about posting it to the DailyWTF at the time but thought that might be bad form when you are the lone contractor trying to rescue the project.]

jerf3• 11 years ago

Now you just need to reintroduce the original function, and call it a performance and memory "optimization", because you no longer have a singleton or its construction to worry about....

spion2• 11 years ago

My theory is that we focus too much on the final points of "best practice advice" and very little on the reasoning behind it.

As programmers, we need to start demanding that logical explanations always accompany best practices or dismiss them as bullshit.

tmuir• 11 years ago

I tried this for over two years at a job, which inevitably resulted in "well, John has 25 years of experience, and you have 5".

dustingetz• 11 years ago

Functions are evil in some languages (C++, Java) because they can't be overridden or customized with virtual methods. In functional languages that don't need polymorphism as much, it's because you can accomplish similar effect with heavy use of higher order functions, which is something that is impractical to do in many OO languages. Functional languages also have their own set of rough edges, FP langauges force an OO programmer to look at a lot of concepts (objects, polymorphism, mutability, encapsulation) in a new light, as they are applied quite differently when you start leaning on functions so heavily. I think if one is in an OO language like Java and starts using static methods everywhere, you end up in a half-way danger zone which can be extremely painful down the road.

Anyway, beware challenging conventional wisdom, it evolved due to past pain and gets passed down generations to avoid that pain, even if the reason is not well understood anymore.

lawpoop• 11 years ago

For the 'best practice' to work, you'd have to make your object accept an interface, in order to be able to accept one with the overridden function that you want, correct?

I think this is the problem with the received-but-not-understood wisdom -- the implementers don't actually use an interface but hard-code the class that has the method, so it's not any more over-rideable than a regular function call.

deadowl• 11 years ago

Functions with closures are as powerful as OOP and can be used analogously.

Also, singletons aren't portable.

mdgrech23• 11 years ago

It reasons like this Uncle Bob pisses me off.

petke2• 11 years ago

We will probably get "uniform call syntax" with C++17. So methods can be called with free function syntax and vice versa. They really are the same.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n447...

mitsoz• 11 years ago

The article is pretty bad.

GalacticDomin8r• 11 years ago

Remember, you can only say nice things on HN. Blind agreement is ok, blind disagreement isn't.

shabbyrobe2• 11 years ago

The section on "Cult Oriented Programming" is also still very relevant today. You could substitute "Smalltalk" for "React" and it still mostly makes sense.

...a programmer's personal preference is more important to getting results than the language or paradigm itself. In other-words, if a programmer can work with the tools and languages that he or she most prefers, then productivity and quality may be much higher than from passing down edicts based on a blanket choice of tool, language, or paradigm.

This backs up a lot of what I've seen over the years and I consider it wasteful in the extreme. Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)."

Yeah, but this thing works just fine as it is. Your job is to improve it without making it worse for the next person, not Reactify it until you've exhausted somebody else's supply of money on a hunt for unicorns.

sgt101• 11 years ago

I'd codify this further with the view that subsituting one set of technical debt with another that fits with local trends and personal opinions is bad. The reasons to program in a particular fashion are as weak as "look how elegant that code is" appealing to the asthetic of the text and layout rather than any actual metric of clarity, reusability, interpribility or whatever.

Goto considered evil is folk law when it comes down to it, I think it's almost universally believed but the fact that I don't immediately think of a crystal clear quantitative result to underpin the view that jumps in code are bad is telling.

I think that some of what is going on here is economics though, coding in the new way gives a good line of patter for the next gig, and we all need to think about the next gig.

JustSomeNobody2• 11 years ago

Funny how GOTO is bad, but "break"ing out of a FOR loop is acceptable. The break is a very specific case of a GOTO.

jacquesm6• 11 years ago

Funny you should write that. One company I looked at was on their fourth rewrite of the system powering their main revenue stream. Every rewrite (by the usual suspects, proponents of some technology with a good babble but less than stellar tech chops) led to a reduction of that income stream, users leaving and so on.

My first piece of advice was to ditch the current system and revert to the old. This had been purposefully sabotaged by the suppliers of the new system. The only way out was then to go forward and this nearly killed the company.

arethuza4• 11 years ago

A previous employer had an application that was very successful (from a business perspective) because it wasn't flexible - they did a lot of acquisitions (one a month at one stage) and if there were any questions around their internal systems they got this application inflicted on them. At first I was horrified (it was ancient, user hostile, completely inflexible) but I actually saw that it worked - the companies being acquired were all in the same industry and their core processes were all pretty much identical (even if the terminology was all different) - so they could all adapt to the new application and it actually ended up working pretty well.

More "modern" flexible applications ended up having multi-month/multi-year "implementation" phases as teams tried to change their new application to their existing processes when it was actually easier to standardise the processes around a fixed application.

shabbyrobe2• 11 years ago

That's amazing that they purposefully sabotaged it! How did they go about doing so?

krylon2• 11 years ago

Maintainable, functional applications are constantly thrown out because programmers don't want to use things they consider "dirty". "Eww, I don't want to go anywhere near that. It's (procedural|PHP|got 'goto' statements|VBA|not the cool thing that everyone's talking about)."

Personally, I really, really don't like Visual Basic. I don't even claim to have anything resembling a rational reason for this attitude. It's deeply ingrained prejudice. And if I have a reasonable alternative to touching VB code, I'll take it gladly.

But I've had to touch a few VBA/Excel based "applications" over the last year or two, and I did it. It was no fun at all, but it was still better than rebuilding those things from scratch. In one case, we replaced an Excel sheet crawling with VBA by a PivotTable which does the same job, is more maintainable, the file is a lot smaller and it appears to run slightly faster.

There is also a part of me that loves picking up some old code written by somebody who has long since left the company, possibly to solve a problem I do not fully comprehend, and fix some obscure bug or add some minor feature. So far, I'll admit I was quite lucky in that those programs I had to touch were reasonably well written, or at least readable and structured in a sanity-preserving way. But still, it's fun, in a way, and the "dirtier", the funnier; at least as long I have a clearly defined task and get to walk away from it when I'm done.

Using the hot new toy that all the cool kinds are using is probably fun, too. But working on a 10-20 year old application that only a handful of people have ever touched, has an appeal that outweighs the distinct lack of sex appeal. Plus, you get to tell some interesting stories about the things you've seen. =)

krylon2• 11 years ago

I like OOP, basically. But as with all things in life, if one takes it too far, it quickly stops being fun.

To think that a) all problems can and should be solved via OOP and that b) it is superior to other techniques (as if it was a competition or a fight) is foolish. To think that some program, that is designed in an object-oriented way, is inherently better than some other program that isn't, is - to a degree - like saying some athlete is better than another one because one wears yellow shoes and the other wears green shoes.

hacker_9• 11 years ago

How is this article front page HN news??

The GUI Link

People think of gui elements as seperate objects (scrollbar, list, tree, textbox etc), so why is it a bad thing that the software also reasons about them as objects? Author just seems to want to hate OOP but offers no alternative: "There is more proof to the existence of UFO's than to OOP being the best way to do GUI's or any other programming topic." ???

Bait-and-Switch

Author says here that training examples lure people into this idea of a perfect world that can be modeled easily with separate objects, but in real life projects this is not the case. But how is this any different from any language / paradigm we have today? Angular is often berated for example for being easy to get going with, but a PITA once the project becomes too big. It's a good thing examples introduce you to the strengths of the language, and then later you try to to fit the problem to those strengths.

Land of Confusion

"It has almost become like Particle Physics, in which only a small elite group appears to understand it properly, and everybody else needs years of meditation and practice." This is silly. Everything has a learning curve, but once you understand that everything exists inside an object you are good to go. The rest is just design patterns that are proven to make your life easier!

Not Table-Friendly

"OOP often does not map well to relational databases"

Entity Framework for C# is used by businesses all over and shows this is possible, and easy to do. There are many other solutions to this as well.

Melding Can Be Hazardous

"How many times do different programming languages and systems have to share data? Very often in the real world. Thus, it is usually safer to keep large data pools separate from methods"

What?? This makes no sense. If you need to share your data structures, then serialize your data to a text format and document it, for the next program to read. You could even provide an API.

IDE support

Well I've stopped reading by this point, but the author doesn't mention any advantages gained in the IDE. Specifically by using objects, the computer has more understanding of what I am doing, and can provide me: contextual autocomplete of members, and contextual documentation. Both invaluable for quickly getting up to speed with a new API, and making programming fun.

fsloth• 11 years ago

"This is silly. Everything has a learning curve, but once you understand that everything exists inside an object you are good to go. The rest is just design patterns that are proven to make your life easier!"

Maybe it's just me but this is my main gripe with OO. I sometimes need to write involved data processing tasks and it's much simpler if I first think in graphs or through a relational model. The objects are light and either a way to encapsulate state (as in parser), a simple structure (as in a vector xyz) or a container.

Complex data lives in relationships between the data - as opposed to 'encapsulating into an object' - this keeps the system small, easy to understand and modify.

Sure, objects are a nice way to offer an interface to something but I've found the statement 'objects all the way down' usually means poor design.

This gripe is of course mainly pedagogical - students (like I was, once) are exposed to a subotimal abstraction of software composition when objects are introduced as the way to design and implement software.

Sure, they are nice in some places, I don't deny that.

pcunite• 11 years ago

I paraphrased one of his statements under the "Split Ends" heading: Advertisers take a small or imagined problem and magnify them to the point of irrational paranoia.

Well said. And that is what is happening today in many forms. I'm under the impression that hiring managers (kids in their 30's) are totally irrational about skillsets because others don't know exactly what they think they should. There is paranoia about making a wrong hire to such a degree that they will most likely make the wrong hire!

What you stare at, you steer for - Bob Goodnough

kabdib2• 11 years ago

I like to tell people about the UCO or "Unencapsulated Composite Operation". It tends to win arguments over "global functions are evil".

Say you have two classes, A and B. You have an operation that uses both of them. You can declare A::func(B) or B::func(A) but this couples the classes together. Yuckko.

So you just make a global function, func(A, B). The function gets its job done using public methods, and the classes remain unaware of each other.

That's the foot in the door. Then you whip multidispatch and CLOS on 'em and watch their eyes get real wide :-)

arethuza4• 11 years ago

Move onto :before :round and :after methods - then finish with the joys of writing your own custom dispatch code.

Leave a copy of AMOP as a going away present.

lackbeard• 11 years ago

Isn't coupling both A and B to the global func(A, B) just as bad as coupling B to A in A::func(B) or A to B B::func(A)?

The thing you're trying to avoid with coupling is that when the dependency changes you might have to change the thing that depends on it, right? Isn't global func going to change with the same likelihood as A::func or B::func?

I'm not sure if this is a relevant or not, (but since it relates to your post,) I do often find myself wishing I had multiple dispatch and/or some way to extend interfaces to existing types when programming in a language without those features.

kabdib2• 11 years ago

Not the same; you can use A independent of B, they are not coupled and you don't even need them both in the product. You're free to change the global func independent of the classes.

petke2• 11 years ago

Thankfully the pendulum has swung back since the 90s.

Stepanov, the inventor of STL (The C++ Standard Template Library) was the pioneer in avoidance of OO. It was truly revolutionary, and had such a huge influence on library design that today most modern C++ libraries are designed the same way.

"STL is not object oriented. I think that object orientedness is [...] a hoax. I have yet to see an interesting piece of code that comes from these OO people. [...] I find OOP technically unsound. [...] I find OOP philosophically unsound. "

http://www.stlport.org/resources/StepanovUSA.html

Object Oriented Programming Oversold (2001)

Related Stories