The Problem with Object-Oriented Programming

Too much software is DRY over KISS. The art is in balancing these two to deliver working and maintaible code.

I agree that object orientation makes it easier to write bad code, but I still like it, because it allows me to write three letter functions, like add get set clr setup init, and so on. Fine, I could do that with modules, but object orientation allows me to eliminate one parameter from the functions too, and one less parameter makes a lot of difference; it's much better.

Isn't this more a problem about how people apply Object Oriented principles as opposed to a problem with OOP itself? "People drive like morons, therefore cars are bad..."

Grumpy old OOP developer here. The real problem is that back in the 80's when OOP was first being created, developers were on average much smarter than developers are today. Back then it was a nerdy niche industry that had no glamour to it so you really had to be drawn to coding. You could extrapolate that back to the 60's and 70's when you pretty much had to be on the spectrum to write software. 80's developers were comparatively socially well adjusted compared to the earlier pocket protector crowd. ;-) It was only during the late 90's and later that it started to become just another career, and one where the common wisdom was that every developer would become a millionaire. The growth of the software industry meant just sort of average people would be getting hired because there's only a finite number of smart people interested in development. Add to that that most of these new guys would be working only in @#$%#!! Javascript because the web was blowing up, and Javascript is still a crappy language suitable only for animating a browser and devoid of any of the more sophisticated abstractions that would stimulate growth as a developer, outside of some superficial functional programming. So that's the state of the industry today: mostly average people dependent on powerful frameworks and powerful development environments. Pretty much an industry of script kiddies, with a really really smart minority building the powerful tools that everyone else is using. So when the script kiddies are asked to deal with abstraction, even something simple like inheritance, they start bleating about how hard their lives are. Why, in my day we had to look up inheritance graphs without an IDE, run the compiler and linker, and maybe even the assembler by hand. Uphill both ways! ;-)
To be fair, you can go nuts with OOP (looking at you, Scala. Higher kinded types?). But it beats what we had before.

I agree that OOP doesn't solve any problems by itself but working with structured data is far better than having functions flying around in headers, being imported god knows why, no documentation at all. Bad code is bad code regardless if you're doing imperative, FP or OOP (or any other paradigm for that matter)

There are always solutions in software. Angular and Nestjs allow you to structure your code into independent modules that hold components.

Im pretty sure you're a Frontend developer you need to know what a web api is. That's kinda the whole point of a frontend developer, pull data from web apis and make them look pretty.

OOP is a tool.
Like any tool, if you use it wrong, it's gonna suck.

Stop blaming the tool and start improving as an engineer.

Damn.... Bro is speaking fact. Thanks, I am guilty of this.

Faulty system design is used as a critique for OOP.

I find oop harder to reason about. Modules are great, and I think it's helpful to tuck away the squiggly bits, so that the flow and logic is easier to follow.

Surely the point about writing any program, is that you need to model the problem to understand it. Then you need to choose a language and model a solution navigating the strenghs and weaknesses of the chosen language.
The idea behind object oriented programming is to build useful objects that model aspects of the solution. Frequently (though not always), this leads to a more maintainable solution, because the objects modelled in the problem mimic aspects of the solution.
Like any tool, object oriented programming can be abused. SmallTalk is nothing like C++, but you can write object oriented solutions to something like the Game of Life in both languages that have a lot of structural similarities. Smalltalk is more "fun" and is faster to write, but C++ is less likely to suffer scalability and portability issues in a production environment.
Programming is a hard skill to master.
...and remember: a good Fortran programmer can write Fortran in any language 🙂

He is right yes. Even if you manage to define a good abstraction it still took you energy to do so. It's like those pagination algorithms that computers use: the threshold at which they are worth it is when they work 90% of the times, and they work 92, but for object oriented programming most of the times you are adding cognitive overhead as well as actual overhead.

OOP can be good but you always need to ask yourself if you are being organized or just fancy. Ask it constantly, and never get used to just being fancy.

In 2006 I've saw my first language was Python 2, I did an small game pretty easy indeed Asteroriods something liket that, but no any classes at all, right now in this world of: interface, abstract class bla bla bla, it's really hard to even do small tasks, I love more functional programming with Javascript a way more descriptive and Python of course, I don't like Java but I use it because they implemented for us the way to think in classes and abstraction and encapsulation and all that tricky stuff, many things have to interconnect each other and at the end of the day you end up, like where the hell it goes this class with this and that, really strange and if you the program in other language it's quite really straight way not so many things.

Not everything needs an interface or base class.
Not everything needs to be injected through DI.
Not everything needs its own library.
Not everything needs clean architecture or DDD.
Follow these and you’ll be fine.

seminar called "why isn't functional programming the norm?" is basically all about the history of OO programming. And yeah, the original conception isn't obviously bad or anything.

Regardless of whether or not you think its good, you have to acknowledge that it did not become ubiquitous BECAUSE of an analysis of the usefulness of the doctrine. It became ubiquitous because of fashion. C++ became the fashion, java was marketted to C++ users and new programmers, and javascript was marketted to java users, and so-on.

I’ve worked with too many people who can’t even explain code they wrote four weeks ago because everything is abstracted away behind services, factories and interfaces that do nothing but juggle data around in the most convoluted way possible. Everything is “maximally reusable” but never gets reused.

And then the desire to wrap SQL which is very well readable in massive “builders” where you have no chance to quickly check what SQL is actually being executed.

Kinda feel the same way. Too many times, we have projects that have so many layers of abstractions (factories, interfaces, abstract classes) for the sake of abstraction. The code becomes immensely difficult to follow and drains all your energy trying to understand what's it's actually doing.
Also, remember the good old days of TheServerSide design patterns overload? Ppl came up with patterns just for the sake of coming up with patterns. LOLs...

I want to know what drugs he is on so that I don't accidentally take them myself 😵‍💫

Oh, we are having "makeStategy" utility at our project. And the author can't get it why it's bad idea. So, I just rewrite it to switch-case statement :) For my 15+ experience I found clear concept - "Write code for peoples, computer is smart enough to make it work, so focus on readability only".

Every time he says right an angel gets it’s wings.

Yep. I've been saying this for years now: abstraction has to be justified by its payoffs. And not everything needs to be abstracted according to the "ideal" OO paradigm. Doing that only brings you closer to being an Architecture Astronaut - not a good thing.

There is a bit of an issue with critiquing OOP (which certainly has issues)in this way: every programming paradigm does not generate code, they are all abstractions. Indeed, compilers are abstractions, they don’t write code and they only facilitate the abstraction of high level programming languages… so there must be a more accurate critique than “OOP doesn’t write code”, for example the amount of boiler plate overhead OOP requires

Btw, I use objects all the time in programming, but I don’t think I have ever conformed to strictly OOP standards

Most of the video referenced in this one is done by someone who clearly has little to no understanding of object-oriented programming.

Today's languages really require a language dependent IDE & let it find the hierarchy and implementation.

I got my first job after college is because I could program in assembly language. Not quite "bare metal", but close.

I had Smalltalk-80 way back when, around 1980.

I started programming in 1974. I know how to use OO, and have written some stuff in OO, but I have concluded that it is not efficient. Writing the software is sort of ok, but maintaining or debugging the code is less efficient. I stopped using OO probably about 20 years ago,
I've written some very large systems, I have a code base of over a million lines of code, none of it OO. I can maintain code I haven't worked on for years without problems, because the code is actually the code.
As for the issue of coding for maintainability, in non-OO systems that is actually quite easy, you just set up some sensible principles and follow them well.
I should probably add one thing. one of the "positive" aspects of OO is the ability to have temporary storage within the paradigm in the form of the objects created during execution, which can be linked into a database through relations.
This is good and bad. It's good because it obviates having to allocate memory structures (or create mechanisms for this) and (sort of) eliminates the need for pointers for linked structures - or, rather, obscures this need. The bad thing is that this is indeed a database, and most programmers can't design databases, so it typically ends up being a complete mess.
My solution was to code a complete memory database and provide a comprehensive API for it - I use this database in every system I design, this completely eliminates the need for objects and classes (the classes become tables in the database, the objects become rows in tables).
This isn't very difficult to do, and it solves the problem in a really elegant and very efficient way.

Got to the Smalltalk thing and gave to in the video. Why are you commenting over the guy if you don't know something basic like what OOP originally referred to?

Why don't you stop recording, do some research, find out and then record? You have Google don't you?


This is incredibly lazy content. You're basically just taking someone else's video, who didn't go to huge efforts himself as voicing over it.

Ffs, this is yt rock bottom.

Honestly there is no cure fore skill issues and corporate politics (Conway's law) -- regardless of OOP, FP or "memory stitching and hole punching" Programming.
Even though I am not in this industry for more than 15 years, I can observe that there are more sheep than wolves when it comes to critical thinking. Be it Scrum - Agile or waterfall, FP or OOP, JS or Java, CloudFunction or Docker, TDD/BDD/DDD...

OOP is like the most elaborate California Closet's design you could possible install in your closet. When all you needed were a couple of wire shelves.

If you try to solve 1 particular well-defined problem for yourself it's fine to use whatever programming language, paradigm and style you are familiar with. You just want to be productive. You just want to the f. result to your problem, you want you to see it working. I feel you. I know only OOP languages and it is so annoying, that I have to work hard/a lot just to make a small thing work. It's sooo annoying!
HOWEVER. If you work for a company that has projects of millions of LoC, which looks like MS Word, Photoshop or something like that, and you don't structure your code well-enough you will end up with with so many bugs, that you will very easily burn-out. Believe me, it's not so fun!

You must write
1) testable code
2) understandable code
3) "skippable" code for reading
By skippable I mean, that you don't write code that is like BIG novel, that you have to read from the beginning to the end to understand it fully (or train your EYES to recognise patterns, "see the Matrix"), rather you make it like a catalog. You skip reading 95% of the code. You just search one particular thing, modify it, and move on.

In other words, in the old time you mostly wrote programs TO the COMPUTER to DO something. And if there was someone smart enough (almost like a genius), they would kind-of understand it, and maybe able to extend/modify it, if they needed some extra feature.
In contrast, in modern days you write programs mostly TO PEOPLE. For still relatively smart, but regular people who need to understand some parts of the code to change them when the business tells, there is a need for new features. And you don't have time to fully understand 15 years old code. But of course, it still have to work. So you need tests. A lot of tests. But it almost impossible to test a function which has 400 lines of code. You must break it into helper functions/methods, and probably to smaller units (classes, files, whatever), too. Actually, it doesn't have to be abstractions in theory, you could split them "vertically", by domain, but most of the times it's actually more convenient to split by abstraction levels. Probably most people think like that.
Analogy: if you build a PC for yourself, you doesn't build it by screw-to-screw or transistor-to-transistor from (physical) bottom to top like it's a lego ship. You buy a motherboard, CPU, GPU, RAM, etc. and join/wire the parts together. And if the PC is not working, you can still test the parts one by one if they work.

Ig the general thing to do is start small, refactor as you go. Its even logical as you cannot see the whole picture to select a proper design pattern when you start your project.

I don't get this... O-O has been completely discredited for 2 decades. This is like making a video about how smoking is bad for your health in 2024.

Nobody likes poor implementations. But you can poorly implement things using pure functional programming. Anything can become a foot-gun. It’s NOT a problem with OO, it’s a problem with the bozo that writes it badly. The same stupidity exists in pure-C implementations or my personal favorite, abusive use of C++ macros. I regularly work on code that passes 30+ intrinsic parameters. Not a class in sight. OO when properly used is elegant. Stop bad-mouthing the power-tool that low-level engineers don’t know how to use.

Well, I think the problem with object orientation is heavily related to the "code-is-your-friend"-faction which mindlessly produces masses of code only for the sake of having said to have reached a new maximum of lines of code per day.
And management enforces that, more code = more productivity.
Until the senior comes up and has to cry about the bullshit the other people have done again...

I could only reuse one of my own class files (ie perl, python, java) as a SysEng if it were ultra simple. And it also had to be very generic. But I'd still copy it to another filename. And import/use that alternate copy just in case it didn't quite fit the bill. In addition, inheritance is always a bad idea. Unfortunately, it's the first topic taught in howto books and college lectures.

There are literally billions of solutions to programming problems. It's about choosing the right one for your particular case.

You should also mention improved testability by using those principals especially for unit testing and mocking

My rules.
Never use inheritance always composition.
Use interfaces.
If for some super special reason where it actually makes sense inheritance max one level.
Start with one file, PODs and free functions only.
When a function and data really ties together create small objects with one or at least very limited responsibilities and more files.
Start with everything public make private when access really needs to be limited.
No getter/setters.
Never use protected, imo the worst source of spaghetti oop never knowing at what level state is changed.
Same rules for templates, only create them when needed, some(a lot) start making template libraries like they are writing new stl functionality while they only have one type.
Same goes for exceptions/error handling/logging other than debug purposes, implement first when it is clear how things turn out and what can go wrong and where, some (a lot) create custom exceptions, complex try/catch hierarchies and logging when all they have is one type cast.
Never future prof anything if you don't know you will absolutely need it.
Re-writing simpler code even from scratch when conditions change is faster than adapting over engineered oop spaghetti.
It is like people are afraid to just delete code that does not solve a problem anymore, building one superstructure to rule them all, only adding to it never taking something out.

Tldr. Start simple and keep it simple if you can, patterns are for cs students 😀

OO lets you draw a wonderful picture, but at that's no use when you want a movie.

OOP is pOOP

Inventor of OOP Alan Kay many times talked that they absolutely butchered his OOP. They just take the name but implemented something that was almost 100% different than what he meant. His OOP is like actor model of Elixir/Erlang .. objects sending asynchronous messages is THE idea of his OOP (async messages is bigger idea than objectes there). But in modern oop objects are connected and using synchonous method calls and its just a very different thing 😢

Premature optimization is true. Thus I don’t mind to refactoring it later. While your boss would fire you before your refactoring, and you leave a bit mess to the next one

They killed goto to prevent spaghetti code they killed procedural to prevent random access global they killed OO to prevent indirection etc..

How can anybody disagree with this video? I'll give it a shot.

First: you don't create the abstractions first and then try to somehow squeeze code into that set-in-stone object structure. This is a ridiculous straw man argument to take down OOP.

It's the other way around. You solve problems while coding and start noticing patterns and almost-but-not-quite the same things appearing. Then you create abstractions to make sure you code every needed piece of functionality exactly once. You use the SOLID principles to guide you: Liskov substitution tells you when inheritance is a good idea (less often than you'd think), Single responsibility tells you what functionality should be extracted into its own class, with it's specific responsibility, and so on.

Second: you program to interfaces exactly because you need to '"add a different dependency to this class [after a set period but 10 years is ridiculous]".

With proper OOP, everything has its proper place and responsibility and if you add something, you already know if it already exists in some form or you need something new. Something that exists can be modified without affecting anything else because of the dependency inversion and other classes just depend on the interface. Something new is just added there and then and the new interface is added as a dependency without a hassle.

If you don't need abstraction, you don't add it. But if you're going to have code duplication and responsibility creep all over your code base, don't come complaining if you change some functionality and end up discovering your change isn't implemented properly everywhere and your maintenance time is out of control.

This feels like a strawman but I'm not smart enough to say why. Functional and OOP are different tools to solve different problems. Being dogmatic about one or the other being better for everything doesn't really make sense. For example the main programming I do is ETL. It's more important for me to turn solutions around quickly than to get closer to the hardware. Different problems require different solutions.

OOP is just a way of organizing your programming work. It helps you think about the problem and constrains you into a certain set of work patterns to help minimize errors. It also can help to manage complexity in a project better.

Yes, OOP can be done badly (bad code and bad design are things), and a lot of the abstraction and modeling tools it provides may be overkill or just a worse fit for some projects.

Personally, I don't have a huge issue locating implementations in OOP code, so I don't get this argument, but maybe I'm privileged somehow.

While OOP is a means to an end and has many useful principles, primarily around managing complexity as codebases and teams grow, it’s ultimately a religious practice that introduces more barriers and confusion than it purportedly solves. This is my gripe with typescript - I see all these barriers and complexity being reintroduced into JavaScript, which became favorable due to its extreme flexibility. You can have types AND keep a simple modular, functional architectural style to keep it simple.