@xiphaliadanlianthol6715
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.
@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.
@DevideNull
Some people may fear they will lose their jobs if the code is too easy to understand.
@mattjones1154
“Polymorphic dispatch in this example is overkill, therefore all polymorphic dispatch is bad.” This video should just be called “Bad code is bad.”
@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.
@arturk9181
I do like object but i treat them as a feature of a language rather than "EVERYTHING MUST BE AN OBJECT!"
@gnir6518
As a student, I learn a lot from these videos and especially the discussions in the comments. Thank you all for your insights
@alexclark6777
"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."
@iAmTheSquidThing
There are a lot of things I like about OOP. But yes, I see your point. People seem to shoehorn a lot of code into objects when they really don't need to.
@InfallibleCode
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand. " - Martin Fowler
@Scarhwk
Half the commenters seem to think that "object-oriented programming" means "code that uses classes." Brian Will was pretty clear that he wasn't saying "don't use classes." He could have been a little more explicit about this, but I think he defines OOP as having three main properties: (i) all of a program's functionality is contained in class methods; (ii) all of a program's data is contained in class instances; and (iii) class properties are all private, or predominantly private, so that classes can only ever directly manage their own internal state (i.e. classes are used to "encapsulate" state). Two things about that: First, that's a pretty reasonable way to define OOP. It's pretty much what I learned in university when they were teaching Java and C++. Second, defined in that way, OOP absolutely is terrible.
@rhymereason3449
I wrote code professionally for 40 years and this type of argument is as old as Fortran. IMHO, OO has its place for certain classes of problems - modern GUIs for just one example. But as with every "new" programming paradigm that comes along there are people who embrace it and promote it as the one and only "truth". The same thing happened with Dijkstra's "Goto less programming"... while structured code is generally a very good idea, there are times when a simple branch instruction can replace a lot of convoluted nested logic and eliminate a lot of cpu cycles popping return addresses off the stack, etc. The same arguments can be found in Relational vs Heirgraphical databases, and even DBM databases. They all have their strengths and weaknesses. Learning when one method is advantageous and when it only adds complexity is part of becoming a good programmer... and being dogmatic (either for or against) any one style in all instances holds one back from being a good programmer IMHO.
@BroddeB
There is no point using OOD for a very simple scenario. But using a complex scenario for teaching is not a good idea. So taking a simple scenario made for teaching, and saying "OOD is garbage" is pretty ignorant
@DavidWoodMusic
I started programming almost two years ago this was one of the first videos I found. I come back to it every six months to see if I understand it yet.
@deckard5pegasus673
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.
@jsnadrian
if this had the title "Roasting Bad OOP", you'd have 100% likes and an empty comments section
@justinhutchison9866
A useful programming mindset that tends toward Brian's style, I've experienced, is to write code that minimizes the number of questions that could be asked about it.
@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.
@MattRamsay-wh6cd
"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.
@Vixikats