Object-Oriented Programming is Embarrassing: 4 Short Examples

[Vixikats]

Actual title: "Overengineered solutions to simple problems are bad."

[xiphaliadanlianthol]

This isn't an argument against OOP it's an argument against making extremely complicated solutions to trivial problems. Classes are powerful but not always necessary.

[MattRamsay-whcd]

"Unified Modelling Language, Universal Modelling Language, whatever who cares... it's f*cking garbage" - that line killed me. You're right, UML is definitely garbage.

[bdormer]

I've been programming for 44 years. Classical, non-object oriented (mainly years ago) and fully OOP. Currently, I manage a system that was 1.5 Million lines of code that I have down to 750, 000 lines (that's HALF) - all thru applying OOP techniques. You have to use the right tool for the job (ask any handyman, mechanic or woodworker). OOP isn't the answer in trivial programs. But in big systems and systems that have to adapt to new business rules, it's invaluable. To just say OOP is bad is a total misunderstanding of OOP. You have to LEARN the tools - not just dismiss what you don't understand. You need to study the OOP subject further before you dismiss it.

[mattjones]

“Polymorphic dispatch in this example is overkill, therefore all polymorphic dispatch is bad.” This video should just be called “Bad code is bad.”

[arturk]

I do like object but i treat them as a feature of a language rather than "EVERYTHING MUST BE AN OBJECT!"

[deckardpegasus]

I could give 100's examples, since I have been working as a developer for over 25 years. But one that pops to mind was back in 2003 or 2004, in a start up company, we developed an extensive video processing, video cataloguing, and video emission platform and the boss wanted a plugin vumeter for the sound volumes for one of the video players. He assigned the task to someone of the team. He took about 2 months to design the complex vumeter with a queue system for the sound samples, etc.etc. and of course all done in OOP C++. The team member was also working simultaneously on other projects, so he did not spend the entire 2 months on just the vumeter.

Even after this, the vumeter never worked properly, and was overcomplex and difficult to debug. The volume levels were all over the place, and obviously did not match the volume in realtime of the video. Even so the boss alloted a big chunk of resourses(2 months of one of the team members) that he was going to ride the sinking ship to the bottom of the ocean, and just kept trying to fix the vumeter to no end.

I secretly took some of my own time, and wrote a vumeter dll in pure C using direct win32 calls(to capture the windows of the app, draw, etc..) and no queue, and no OOP. My vumeter when compiled was 64 kilobytes and had no external dependencies(and probably was even smaller but Windows has a cap due to alighment on PE sizes) My team member's vumeter was well into the megabytes and had various dependencies on third party dlls, sdks, etc.
In the end, my vumeter worked perfectly and the company had to use my version. My boss took me to the side, and was extraordinarly pissed off at me, almost screaming, yelling: why the hell did you make a vumeter, taking time you shouldn't or you could have just helped with the main vumeter project etc.etc.. I have never seen him so mad. Even so the main vumeter project was completely trashed and they only used mine for years to come.

The reason I did not participate in the main project, and just went off and did mine, is that every time I spoke up about overly complex code, and OPP, I was pushed down and ridiculed directly, so the was no reason to argue with people and their devout dogma, I just did what needed to be done.

[DevideNull]

Some people may fear they will lose their jobs if the code is too easy to understand.

[InfallibleCode]

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
"
- Martin Fowler

[alexclark]

"Hammers are bad because not everything is a nail; here are some examples of people hitting screws with hammers to prove why hammers are terrible."

[gnir]

As a student, I learn a lot from these videos and especially the discussions in the comments. Thank you all for your insights

[MrDocProfPj]

After just taking an OOP class at college, and appreciating what it is does, the majority of our coursework was small examples that could easily be done procedurally including the final that I felt force to complicate with classes I can respect what he is saying but I also can see the large scale use cases.

[jsnadrian]

if this had the title "Roasting Bad OOP", you'd have 100% likes and an empty comments section

[BlueBetaPro]

Object-Oriented Programming is not some omnipotent tool that makes every bit of code it touches better. OOP is just a tool in your toolbox of patterns.

Saying we shouldn't use a pattern is as wrong as saying we should use it everywhere.

Forcing any pattern is generally not a good idea except it can be a good learning experience.

Use the pattern that matches your problem.

[skyflight]

I agree, the examples went to absurd lengths to make everything an object: when your objects are actions like 'job', or 'marshaler' there's a problem. ... I sat down to eat breakfast with my bow and arrow but couldn't really get the cornflakes on my broad head.

[leighdf]

I'm with you 100%. Using a function is basically saying "Do [something] to this data", where [something] is described by the function name. So functions are readable as hell. Put your branching logic in one place, and then for every if-then or switch that isn't trivial, call a function. Such code is readable, understandable, maintainable, and compact. You know exactly what happened to the data just by looking at it. You know exactly where to go to extend the code or fix a bug. The thing is, when you're working in a corporate environment, you're probably not the one who maintains the code you write (and are probably didn't write the code you maintain). I dread stepping into someone else's OO code... it's a shot in the dark, and you DO need to understand the whole system, or you can't prevent bugs, much less easily find them. OTOH, you can just step through a procedure and understand it quickly. Every time I've seen someone tout the advantages of OOP, they trot out a piece of procedural -- but not functional -- programming with heavy logic in the control structures; so it looks far more complicated than it needs to be.

[Zachucks]

I'm not sure you can just say "OOP is bad", the examples you are showing are a bad use of OOP. Doesn't mean that the idea is just null and shouldn't be used.

[nobodyspecial]

C++ programmer here—I've dabbled in many languages, but C++ being my favorite, I used to be a Java programmer.

I just find it amazing how toxic the programming community is and how dogmatic everyone is.

[UrSoMeanBoss]

I like the modern C++ approach to classes. In short many industries have largely abandoned OO philosophy and they just use classes as ways to tie data to the behavior that operates on it, and for RAII principles (mostly just resource management). Classes aren't bad; how people use them are often bad. OO makes it easier to write bad code.

[rickchristenham]

I am an OO programmer and never had a problem with absurd examples like these. A class is not always a data object, for example, a service. A service, like "logger, " for instance is just that: A logger. Classes to me are ways of grouping and organizing your code. Consider that all Microsoft and Java frameworks and libraries are OO. For example, a String class is an object that both represents a string and contains methods related to manipulating strings, etc. If OO programming is so bad, then the Java and MS languages/frameworks themselves are likewise nonsensical as well and its no wonder that we're able to use them at all. I mean, in procedural programming, it's not uncommon to have a procedure named something like "ProcessOrder" for instance and it usually performs all the steps needed to process the order, but you are often not sure what that all entails. If you ever need to isolate and find the code that specifically performs a certain action like determining the tax rate, would that be in the ProcessOrder procedure or did we load that value when we say chose our state? Or maybe we were able to determine it upon initialization. I can't tell you how many times I've had to search entire applications searching for where a certain piece of logic lived. It just makes sense to place tax logic in a "Tax" class. It keeps us from trying to guess whether or not we decided to put a certain function in a module that we named "GlobalMethods" or if it's in the module where its being used, etc. It just makes more intuitive sense because that's how all frameworks, controls and packages that I've ever used were organized.