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

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.

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.

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.

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

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

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

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.

"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."

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

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.

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

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

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.

"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.

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.

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.

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.

7:00 pretty much is something i love about this vid. I mean, i dont agree with the overall idea that OOP is embarrassing, but lets be honest: that class was being used as if it was a namespace, and thats a problem many classes fall into... thats why i think it is very important to think of classes as structs with functions that do stuff to the data they contain. Its like having a struct to contain stuff and a function to affect it, but instead of having the function be external, you have the function inside of the class so you know it is associated to that kind of data. Cases like the one in 7:00 are displays of why overly complicating code really makes no sense. Why would you need a class to do all of the work that class is doing? all of that stuff is far better off as individual functions, put them inside of a namspace if you want to make it even more clear that they are related somehow.

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.

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.

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.

In closing you're referring to the OOP concept of encapsulation I think. I think this is possible because we do it with third-party libraries. Most programmers that program in a high-level language use several third-party libraries that handle things that would be a whole project in their own right like parsing and creating Excel spreadsheet files. You don't have an in-depth knowledge of what these libraries do to use them. You also can't harm them in any way by changes you make to your project code.

I've done very little OOP and am likely the least experienced person here, but a hybrid approach seemed best for my current project. I'm using an array of structs for my "objects" (in C), and I could have included in each struct a function pointer to further emulate the OOP scheme, but it just seemed to complicate matters. This will be a CLI application. But when I write a companion program with a gui it will definitely be object oriented to handle "events" and certain drawing elements and styles on the canvas.

This seems like more of a "don't put crap into objects when you don't need to" than a case against OOP.

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

Brian, I think I kinda agree with you. Thanks for the techniques that you had given in this video. They are really awesome. I think I get what you really mean, it is not about object or class that matter but it is more about 'object-oriented' that gives damaging and false hopes in many ways. That's why it leads to over abstractions and too much thinking on maintainability that leads to too many classes for such small solutions. Now I think we should be careful about the notion of 'object-oriented'. It should be a guideline and not a religion. We should embrace procedural where possible but still we could maintain clean code and SOLID. Thanks.

For me it is just a matter of maintainability, readbility, and a little of reliabilty (a.k.a don't write code unnecessarily hacky). If you prefer procedural, fp, or oop, go for it as long as I can undesrtand what you had on your mind when you wrote that, or better, as long as a junior can understand what's going on. Personally I don't take it too seriously, sometimes I would use oop just to encapsulate methods, other times to encapsulate state, or just use procedural, fp or whatever feels more convenient. What I would not want is a soup of miscelaneous functions which do a lot of unrelated things, since in that case you would need to memorize all code to know what to touch and what code breaks what.

The thing is that where ever you look for examples of OOP, you'll find vastly over-engineered code. This isn't because OOP itself is bad and leads to bad practices, it's actually because the examples don't play to the strengths of OOP. And understandably so, since oop is meant to be used in large codebases so you can keep everything modular in case you need to change something. And by the nature of an example, the code for it can't be a huge codebase or program. The conclusion you should draw from this is that both styles of programming have their place where they work best. There isn't a one-size-fits-all solution. OOP is a tool, not a way of life.

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.

My favourite thing is writing procedural code and using a class as a short-live container to make it more declarative. First imagine a 70 line method. Then split it into separate methods. In a mess with variable passing spaghetti because it turns out both method 1 and method 4 need a particular variable? So replace the variables with memoized calculated properties. Ruby uses the @myvar ||= idiom. Python has @cached_property decorator. The caching isn't mainly for performance. It makes your vars more like constants, thus easier to reason about. That is not OOP but quite a lot of other common and good uses for classes are similar.

I like using oop not for competitive programming kinda problems .but for other projects : one time we were asked to make a programm that does alot of things with a train ride including tickets ,distinations , travelling time , and other aspects that u take in consideration if travelling by train . So making a class for that was really neat to deal with .

I've been a software developer for over 30 years now .... currently I work with C# a lot ... which I love because it lends itself to both procedural and OO paradigms really easily. If I'm cobbling together a little in-house utility I will always use a procedural style ... it's quicker and I'm not expecting the code to need to be scaled up in any way. For anything bigger and anything that customers will use it will always be OO. As other people have commented ... OO is scaleable in a way procedural code is not. I always think there's oceans of difference between a "software scientist" giving opinions on small and contrived programming examples and actually getting stuck deep into countless thousands or millions of lines real world code.

Very fascinating thought process. It seems clear that you don't despise the use of classes and objects, but that, to use them there must be a reason for them to be used. Much of (if not all) the OOP examples you've picked apart here are quite clearly unnecessarily complicated, not because the author thought that the problem needed to be solved by OOP, but simply because they were trying to give a demo of OO concepts. Unsure if you've already made a followup to this yet or not, but I'd love to see you pick apart real OO projects like you'd mentioned in the video. (namely a small game) Those projects *should* contain OOP examples in which the developer felt that OOP actually offered something.

You have demonstrated in a very concise way my own journey in adhering to the design principles of OOP. When I attempted I found myself getting lost and making things less readable and concise just to fit the patterns of these expected principles.

Hey man I totally agree with you, I feel like many problems are overengineed to the top and then it's so hard to understand a very simple problem.

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.

I think the main point is: "Know your tools and how to use them. Less is more."

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.

I would like to hear Uncle Bob's reply to your observations about his code. I agree 100% with you about OOP creating a lot of mental overhead that often isn't needed. I have also seen some examples where OOP really can be very slick.

"UML is just fucking garbage" -- You're my hero, Mr Brian Will.

I'm self taught in C++ and through the years I've learned that when you don't need OOP you shouldn't try to force it. However if you do have an object that has several fields and you to keep the data encapsulated (protected or private) from the user and just provide an interface then yes by all means it is worth it in that sense.

I guess it comes up to personal preference for making sense of things. I personally much more like OOP because it allows me to categorize and therefore organize things effectively. If you don’t enforce any boundaries, then it just keeps possibilities virtually infinite. That might be fine for some people, but for someone like me that just becomes overwhelming. Being able to parse things into categories makes everything more understandable. Sure, it’s all data, but by enforcing restrictions on types of data, you can help communicate specifically what each thing is for, and with limitations then you can know what any given thing can or cannot do, based on what it is.

According to my professors, that last argument you touched on (about OO making it so you don’t need to know everything to use code) is the only real point of OO. That said, it’s an extremely valuable benefit and I couldn’t disagree more with your take that you should need to know how literally every part your software works. That’s totally unrealistic with any large-scale codebase, and nowhere did I realize this more than at my AWS internship. My first instinct was to try and understand HOW everything worked before I did anything, but you can’t move at a pace acceptable to customers if you try to do that. You absolutely must be able to have as many segments of your code as possible that you can just think of as a black boxes with inputs and outputs and just assume that they do as described. Being able to get by with only knowing WHAT a piece of code does without needing to know HOW is crucial to working at the pace that customer focused firms require. In other words: yes, OO can make it so your code is way harder for others to understand, but that’s because the point is to make it so others don’t have to understand it at all. Function based programming is a much better redress to some of the issues you raised with OO because you can still get this crucial “black-boxing” ability, but don’t have to contort everything around OO dogma. Great discussion to have though, even if I don’t agree with all your points.

"Nobody would actually ever do that." I have. I worked at a company with ~1 million lines of code written in Node.js with a functional style. We rewrote the entire codebase in an object-oriented style using TypeScript. Not only did it help us find and fix many bugs but it made the code more maintainable and let the company scale when previously development had slowed to a halt. The main thing I observed was that allowed us to separate concerns, more easily share code, and eliminate side effects.

It has been known for a while that OOP is superfluous when it comes to simple programs with less than ~1000 lines. The entire point of OOP is to make things more accessible. You cannot argue that the java developers did not use OOP properly. Seriously, can you even imagine the java API existing in it's current state if OOP was not a feature of java??

You can always take an example and say "uh, I don't need all those classes I could just do this" And that's the issue with examples: they're just that, examples that can't possibly represent the whole picture of what you'd actually be doing in a real code base. Take the coin flipping game program for example: in itself, it's really simple and I would argue that even YOUR code was already too complicated, you could have written everything in the main just fine. To which you'd probably reply something like "yes, but as soon as I need to be able to play from somewhere else in my code it gets hard to read..." and you'd be absolutely right, that's why we have functions. Now imagine that you're using a game engine, with a player, a myriad of other types of entities etc... The developpers who made the engine didn't just have your little coing flipping game in mind. In an actual non-trivial game, even the player becomes a potentially really complex entity, with a lot more data to handle, and a lot more interfaces to handle that data. You need somewhere to store said data, and functions to interact with it, a class provides both at the same time in a single place. And then there's inheritance, abstract types and all these things I won't even try to discuss here because it would get way too long. Case and point being that a limited set of really simple examples (however well chosen they might be) is going to fall a little short for demonstrating how powerful OOP can be. Over engineering is bad, that's something we can agree on. But if you want to make simple example, obviously you'll have to do a fair bit of it, because I think you'd be equally as confused if the example consisted of a super complex library that actually takes advantage of what OOP has to offer. It's a tradeoff. Of course we can write simpler code, but that's completely besides the point.

As a hobbyist I appreciate this video. Recently I "converted" some of my scripts to include classes, because surface level research suggests I should use classes, objects, methods. And the result is that I create a single use class that does the exact same thing the function did and is never called again in the entire script. "Objects" are useful with actual objects. When I want to build a GUI for my script, it's nice to have a button class that handles the button name, the display text and the function it calls and I can define everything in a single line. But for the config files I think I need only two basic functions: load it and save it. Whatever happens in between these two actions can also be done with functions. Maybe if my script required 5 or 10 config files it would make sense, but that would no longer be a script, it would be an actual program.

I once maintained a project that was developed by a guy with exactly this same philosophy. It was hell. Nothing but long, mono-classes with godlike powers. What you advocate here makes sense - for small examples/apps. Once the project gets to a certain size, the 'embarrassing' separation comes very handy.

Isn't the purpose of all those examples you go through to teach OO programming? Sure, they can be simplified and optimized into less and arguably more readable code. But i think they abstract them out further than most would in practice, for the sake of simplifying their teaching points.

For the Gilded Rose kata, which you solved with a switching branch, the original assignment is to extend the system with additional products: "Comjured" items. The assignment also says: "Feel free to make any changes to the UpdateQuality method and add any new code as long as everything still works correctly. However, do not alter the Item class or Items property as those belong to the goblin in the corner who will insta-rage and one-shot you as he doesn't believe in shared code ownership (you can make the UpdateQuality method and Items property static if you like, we'll cover for you)." How would you tackle that?

7:25 static methods or singleton patterns should solve the 'instantiate to use' problem Also I don't really think the 'core purpose' of oop is to think of everything as objects and put boundaries and stuff, instead the objects are just basically data types like structs, and the extra stuff that comes with classes are just the same stuff in procedural programming but organized in a different way. For example, there are a lot of functions that are made in procedural programming which 'does xxx for data type xxx' and oop allows them to be organized into their respective data types(classes). And by doing this, it naturally feels similar to real-life objects which also have states and functions, and that's why people use and make them like the objects in real life. Also, inheritance, which is another feature of oop, is at its core a way to group objects, so the functions and data wouldn't be repeated. And then there are classes that are used like namespaces by using singletons or static methods. Basically all programming methods are there to reduce repetition; oop is just like functions and structs. It is not some kind of a religion that people have to follow, but just a tool. If it's not the tool for the job, don't use it. If it fits perfectly, use it. And nothing's stopping you from mixing some styles up, using the right styles for the right parts of the code.

How bout multi paradigm programming, everything has it's place... A pure anything would probably not be the best way

You ask the question multiple times, "why is this a class?" And the answer is, ideally, "because it's a highly cohesive unit of behavior that is going to be injected into another unit as a dependency." This allows clean separation of concerns into units that can be tested independently using O(n) tests for the functionality of unit N and O(m) tests for the functionality of unit M, and not O(n*m) tests for the functionality of both those units together where you have to test the cartesian product of all code paths both units could take. OOP doesn't have a lock on this. You can do the same thing in functional programming by taking dependencies as functions and implementing those dependencies as closures over any necessary inputs. Hell, you can do the same in procedural code by using function pointers. The benefit you get, that you're erasing in your rewritten examples, is the inversion of control which requires a callee to be able to dispatch to a method specified by its caller. None of your examples do that, which means none of your methods that have dependencies can be tested independently. It also means you can't pick and choose between implementations of cross-cutting concerns. You couldn't swap in an HTTP file reader in place of the FTP, you couldn't swap in an XML file parser in place of CSV.

18:04 A much simpler solution to the same problem would be sum-types (or just enums in this case), since in that case, the compiler will still ensure that you cover all the cases and you don't have to awkwardly bundle together a single case for all the different functions in a subclass. If you really want to bundle it that way, it's still possible with sum types, you just have to do it manually.

Wow, nice! This is great. Large systems, let's say Salesforce Commerce Cloud, are written in Java and have a rich OOP design, BUT when we write code to use the system it's 100% procedural because we don't need to re-write the object model, we just need to use it do work with code. This idea has greatly democratized development and allows simple, fast solutions to problems.

coin flipper: console.log(Math.random() > 0.5 ? "tails" : "heads")

as a regular user of Java, i can see where you’re coming from and why you’re saying OOP is bad. i use Java for bigger projects in which it is nice to have objects and such for the organization of the large codebase. as many people have said in these comments, OOP is terrible for small projects and wayyy more useful for bigger projects.

If you are using the class as a namespace you don’t need a “useless instance”, you can make the methods static. The “instance” is only useful if you are following an interface where you can swap implementations.

I like pure functions, but sometimes also feel better to use a class. Programming languages that allow you both are best IMO.

For the first example, you said “you need to instantiate classes”. What about static methods in classes? They could have work in that case and as you said the class would have served only as a namespace for code separation ( so it won’t be in the global scope )

Brian sounds like me while revising my own code after a few months.

Honestly, the only thing I regret about learning Haskell is that it makes using any other language painful in comparison. Rust and Scala are nice but Haskell will always hold a special place in my heart.

There is a massive difference between how you code a small app vs a large app. For example, weak typed languages are great for small, little things because you can whip them out quick and without a lot of planning and design. However, large applications are best with strongly typed languages as the large code base makes it very hard to keep all the data structures and names of variables, classes, functions, etc. in your head. Likewise, OO vs. procedural vs. functional languages have their strengths and weaknesses. For example, with a large Java Spring Boot application, I want to create well defined interfaces that my code talks to. Then on startup, the application will construct implementations that may vary from one implementation to another. With Spring, it creates singletons of the controller, service and DAO classes so we are not constantly creating and destroying objects. These Spring beans might actually contain other objects like a DataSource which is used to connect and talk to the DB. The beans could also do some caching or hold configuration or so many other things we would need to make the application configurable, scaleable and fast. When you start to have an application with 10's of thousands of lines of code in it, just having functions and data structures becomes very limiting. Basically what I hear the complaint about here is more around not using the proper tool for the job at hand. Sometimes OO is a horrible choice (like small and simple sets of code). Other times it makes the code clean, well organized and versatile.

When pursuing dogma, you inevitably find a plethora of examples where that dogma fails to accomplish. Data analysis should give way to action precisely when it needs to.

The examples do not prove that OOP is bad, but simply that the examples themselves are badly coded.

Both have pros and cons, but I clearly see your point about the over doing / over thinking things. Regardless of the tool, I think it’s critical to spend more time properly naming things.

Hi I’m a beginner. So am I understanding right that OOP overcomplicates coding for most applications that procedural or functional programming can do? Is that the general message?

I think you are always going to be able to find examples like this. OOP's strengths are in its ability to scale and to have abstractions. Small toy examples will always look better as procedural code because they don't need to leverage those strengths.

there's a balance which is very hard to strike and very hard to show on examples. in the terms of real production code all those examples are insanely, absurdly overengineered, the last one even in a very weird and hostile way. but in terms of real production code you need a text that primarily preserves and presents the logic, principles, mindset behind the program, so the next programmer can understand and extend those principles for new cases with relative ease... what you propose in all the cases is "specific minimal elegant code to solve the precise given solution". what OOP is about is "the problem presented is an example of a problem set that will expand, catch the principle and make logic that will be easy to expand and relatively easy to comprehend in general even when in almost constant state of flux. (disclaimer: i say "functions". we are not talking about functional programming, yes. we're talking about procedural. when I say functions, i mean procedures, methods, whatever you call it. for me a function is a block of code optionally accepting parameters and returning value. method/procedure i'm used to think of as a block of code optionally accepting parameters and directly manipulating data within parent (i.e. global, or object) scope, not returning a value. you knew what I mean, this is just defense against nitpicking :-D) object oriented thinking is just more akin to how our minds model the world and events within it, therefore people will be better at using it more readily for larger problems. it is also more suitable for solving/simulating complex interconnected systems. you prefer to think of data as data, and functions as functions, "the program", "what is being done to the data". i prefer to think of data as "data program was made to manipulate", and functions, objects, code as "data that describes what to do, how to transform the target data". so that makes me think of a function/method as a type of variable/object. lambdas, delegates, reflection. all the examples are shit, though. any example any talk or OOP design tutorial ever gave is total shit. until you are sat in front of a corporate solution with 2 milion loc, 150k of it autogenerated, divided in 8 projects (database access lib, webservice libs on top of it, and several apps (from MVC through silverlight through MS CRM extension lib to angular SPA) some using the DA libs directly, some connecting to webservices, some connecting to crm and webservices and creating another webservice for a different system with the combined data...)... until you encounter a beast like this, and after the initial mortal dread and the first stressful month you realize that you can already work within that code with relative effectivity... THAT'S when you start to understand: a) what is the point of; b) how to correctly use OOP. but of course there's boatloads of shit and shitloads of bloat in app architecture in any area... also, procedural-oriented creates hideous function names. example: windows api. c api :-D still, I understand most of your points and I've agreed with them for a long time. OOP is interesting that most of its features seem useless unless you specifically encounter a case where one of them helps you (sometimes to a ridiculous degree) reduce code complexity and increase readability. after that, you start seeing potential application of that feature everywhere, even where it's not necessary. when you again realize where it really is necessary, and where it isn't you've mastered that feature :-D most of that features, at least in recent years, were made with huge corporate systems in mind, therefore to truly understand them, you need to encounter a huge corporate system scenario.

I use a more down-to-earth definition of an object: it has state, and an interface that prevents putting the object into an invalid state. An OO language has rich features for defining an object's interface. In such a way that attempts to access the object in ways that violate its proper interface will result in compile errors or runtime exceptions. Many maintainability problems with code fall under the broad category of failure to follow the KISS principle. Since OO languages need features to support OO, those features can be over used, in violation of KISS. For example, a object representing a point in a plane can have x and y as public data members. Because this doesn't make it possible to put the object into an invalid state. If the object were a point on a circle, it could not have x and y as public data members in that case.

One of my first programming jobs, I worked on a project written in C++. It was reasonably sized, about 500KLOCs. I came up with the term "object oriented spaghetti." OOP doesn't protect you from spaghetti code at all. I was thrown into the deep end doing debugging. So I had to do a lot of call stack tracing. This was financial trading software. You could think of it as a retail version of a Bloomberg terminal.

"Im just gonna use a small example to demonstrate this OOP concept" "oMg YoU uSe AlL tHeSe ClAsSeS fOr SoMeThInG sO sImPlE??"

OOP goal is not to facilitate reading but to improve the process of change. It gives us the opportunity to substitute with code injection without changing or damaging the overall structure

Whenever I try to keep struct and functions separate, I start to miss features classes offer me. C'tors and d'tors for example. It would surely be possible to go without them but then I have to manually call them in the proper places which - for d'tors - is not a trivial pursuit in some cases. I use classes to bundle various states and behaviors which communicate with an external system to build a somewhat simple interface for the rest of the system. Is this a bad thing?

It’s interesting to me how objects are meant to help better understand how data interacts in your application, but it ends up making it more complicated when it’s not needed.

Here is what you did wrong: You chose examples that were made specifically to showcase OOP. Of course they are over engineered. OOP becomes useful when you need repeating patterns in large programs. Or when you need to access the same objects/data from multiple places. This will never be necessary in 100 lines of code.

I was there in the early 90's when OOP started to emerge. I loved it. OOP encouraged developers to better analyse the problem and define clear structures. With the finer grained modules that resulted, version control (exclusive locking - which is all that was available at the time), became more manageable. Who remembers Borland Delphi? The early Gurus were at pains to point out that OOP isn't anything new, it is what you should have been doing all along (but nobody was) with some extra features. Fast forward 20 years, it seems programmers had all been moved to the "Work Prevention Department" en masse. The utterly irrational and insatiable need for 'gurus' to patternize, abstractize, distribute and XMLize everything had me shaking my head. The equally irrational and insatiable need for developers to follow the Gurus effectively ended any possibility that IT projects could host productive teams never mind there being any danger of them delivering robust, effective and performant software. In the latter stages of my career I was involved as a decision maker in various projects under various hats with titles like project manager, technical lead or architect. Invariably I managed to steer the teams away from the trends and managed through constant evangelising to get them to produce as little code as possible, concerned only with delivering functionality and performance for which there was actually a requirement. I found it easy to create productive teams who always delivered. I never understood why other managers were at the mercy of their tech heads, who clearly forgot what they were there for - to deliver software.

Having been in the computer science racket and then later owned a software development shop for over 20 years, this video really points out problems with both the author and the industry. Of all developers, only 10% can manage OO. The rest should stick to procedural and, to boot, not write large and complex systems. Of the remaining developers, less than 1/10th can manage functional programming. Those aren’t good odds for building a business or industry. What this author is ranting about, I suppose, is all these rules and acronyms that are meant to help the developer who lack the cognitive ability to write OO code produce something useful. I’m not sure that he understands that’s what he’s doing, though.

Hey Brian. I totally agree with your assessments both here and in your original video. The one thing that keeps pulling me away from C and back to C++ is the container classes. Things like the map or vector classes are so useful and needed. Can you recommend any resources for learning how to do this in C in a simple way aside from the typical linked list examples out there? I really want to get away from C++ if I can only figure out this one aspect. I would also add that I like the idea of using a hybrid approach such as using classes minimally and only when it makes sense. Nothing to stop us from using a plain old library of functions in C++ for everything else.

I largely agree, but I have two objections: 1. Specialized types enable compile time checking. Having a CommandLineArgDefs type (sorry for that name, there's probably a better one) instead of a hash map makes it possible to check whether you accidentally are using some other hash map (with the same key/value types) in that context. Of course OOP doesn't do much to help you with that - something like Haskell's newtype is much more appropriate. 2. The use of polymorphism as shown by you is a matter of taste. You don't like it to do the things you've shown here and that's fine, others feel differently and that's also fine. But polymorphism has another advantage: It allows someone else to expand upon your code without having them change it. As an example, take a language that has a more complex notion of what a number may be (and sees operators just as functions with infix notation). It already has '+' defined and at a place where a programmer cannot change it (and thus cannot add to a large switch statement). If the programmer adds Complex Numbers or Surreal Numbers or anything like that without polymorphic functions would need to define a new function, like "add" maybe. With polymorphic functions the can define a new version of '+' for all relevant combinations of differently typed numbers. This has the added benefit that, in a language with proper type inference, a whole host of other functions defined on top of '+' now also may work correctly on these newly defined number types. The same goes for libraries.

I personally find UML sequence diagrams very useful when faced with undocumented, unknown code and trying to find out how it communicates with the rest of the system.

Brian, other approaches I have considered are these. Your point about UML is something I partially support. At the beginning we are often answering more questions than we can answer.Iterative changes will come if the application is used and lasts any amount of time. Instead of which is superior, how about considering the strengths of OOP and functional code and creating a mix? There is another flaw in teaching it is bad when it creates a win. There are better wins possible, but the debate on better wins is far different than good and bad. My perception there is if you don’t win like I win you are not winning. Or, if your win is not as profound as my win it is bad. I do realize you are not the originator of this debate, so this is something too many of us have accidentally joined comparing apples and oranges. The end result is oranges suck because. We can show how apples are better fits. P.S. When this whole debate was ramping up there used to be a teaching of Pure OOP.. I used to as similar questions in that season. I called OOP ravioli that hid complexity vs procedural done as spaghetti. Spring files became the new location to store confusion during that season. Granted, spring has definitely improved but OOP went woke on procedural in those days. My quest, agile code that is sustainable. Reduce technical debt and fulfill the why to business needs above the how.

What do you think about when we are modeling physical systems? There are a lot of systems with memory, and representing these states as class fields feels natural. The procedural way would be to use persistent variables, global variables, or carrying the previous states all the way in an out throughout the functions?

I agree with a lot of what you’re saying, although I will say that objects are to be used when you need persistence for property values and I’ve re-written a lot of procedural code due to this

The example where you refactor the polymorphic solution into a switch statement is a good example of cleaning up code. However, I don't think this is strictly an issue with OO; rather, it is an issue of expressivity. In essence, Item is a typed function. That is, it's an interface (a base class since this is Ruby) with a single method. This switch statement solution is a closed system because the only way to change it is to modify the code. This is an example of the expression problem. Polymorphism is one way to deal with this because instead of hardcoding the cases, the caller is required to provide the case they're interested in. I agree that this is overkill for this small example, but I think it's important to point out that this is very useful in scenarios where programmers do not control this code and need to be able to extend it. The same thing is true for the argument parser example. You're taking a general solution and making it specific. This is all well and good, but defeats the point of making the solution general. I agree that general solutions are not always useful, but they still are useful. And they don't have to be implemented in an OO-style. These issues transcend OO design patterns, which is why I brought them up.

I agree 100%. Classes are extremely important, but sometimes I just want to hard code something "the dirty way" because I know what I'm doing and why I'm doing it. This is probably why I love C++ so much, because it allows me to make that choice myself. You have to be careful though, because if you only have a basic understanding of the language, things can go very wrong very quickly without you even realizing it, which is why a lot of people try C++ and quit.

My biggest gripe with OOP is not so much the implementation/application, but the syntax. Holy hell, who came up with the syntax for Java??? It's been one of the hardest languages for me to master because there is absolutely no consistency in the command structure. For example, HTML and CSS are simple and no matter what you're trying to do, the application is always the same -- with the former, you have an opening and closing tag. With the latter, you declare a name, then assign properties to that name using CSS. The name is this called from anywhere in the code, and the assigned properties will be applied to the element. In Java & JS, virtually every action requires a completely different set of rules. Arrays are defined like methods, but ArrayLists use a completely different syntax. Identifying an index position in an array uses one thing, but identifying the index position of an ArrayList requires the get() method! Assigning values to variables uses the = operand, but assigning values to an array requires the = operand AND curly braces! Methods can be void, or they can be defined to return specific data types...why? Why would this make any difference? If you require the user to input an integer and an letter is input, just program an invalid input response -- won't you need that anyway?! The more I've learned about Java, the more it just seems like a frustratingly messy language.

Write about 20k lines of code (LoC) for an initial release with 3-5 devs and a formal scrum/kanban team, expect another 50-70k LoC over 5 years from 20+ developers of various competency. For your code contract, write unit tests, component tests, contract tests, and integration tests. Let's also consider exposing the API, versioning, documentation for the end user and the developer, performance and logging. What if we want to extract functionality from the app for use in other projects or maybe convert it into a library or smaller (micro)services (because now you have the budget for horizontal scaling)? There is a balance between ease of development, maintainability, testable code, and performance. Procedural code is fine in the scope of one-off scripts. When it comes to releasing an real app into the wild... I'll stick with OOP as part of the development procedure.

"Hammers are better than axes!" *shows examples of nails to be clubbed into a board*

27:06 👏👏👏👏👏 I agree 100% with you Brian. In my years of software development, I continue seeing efforts made to "make programming easy" and hearing claims that "programming is not hard". These two beliefs are pervasive and affirmed by the industry to lower the bar of entry to just anyone. Books, weekend bootcamps, "Hour of Code", etc. all contribute to flood the software development market with low quality workers. Tool, library and framework makers work tirelessly to abstract complexity away (typically just moving it elsewhere) so programmers "don't have to understand" what or why they are doing what they do. When asked, they'll parrot: "Industry standard", "there's a tutorial", "experts agree", etc. Scary times we work in.

Sometimes the libraries necessitate OOP, and it makes sense continue the OOP style when it fits well with existing code. You can't escape it if you use python, and I've found that I need a solid understanding of CLOS to integrate with many exceptional Common Lisp libraries.

As a software engineer with 30+ year's experience, I can say that this video is embarrassing.

I can say that OO design has helped me tremendously throughout my career. Simple patterns such as Factory, Strategy, State, help sooooo much when dealing with complex problems.

Just found this video (you will probably not even check comments on a 6 year old video). I am so pleased to find a like minded person regarding Obeject Oriented programming. I have been a software engineer (yep different to a coder) for 30 years now mainly working in real time embeded and safety critical so my view may be different to data analyst environments. So refreshing to hear a view other than OO is great and the future no matter what. One point I dont agree with you on the use of suitable design (not UML). Sitting down to write code before planning structure, units etc in not a good approach in my view/experience. Other than than, great video!

Highly recommend you look at structs, interfaces, and binding functions to them in golang. Go is not object oriented but you can do all oop things with go. The biggest difference is it removes all the things you (and I) don’t like about oop and it’s not true oop. Everything is more explicit and there aren’t class methods and structs can be used to represent objects but it mainly is about data and variables in a simple but organized way (analogous to a dict for key value pairs) and can still fit with a functional paradigm.

In your Python code, just type: import this Run the code and that's all you'll need.

I like that you acknowledge right in the beginning of the video that the strongest argument for OOP is in large, complex programs, then proceed to not look at any large or complex programs and conclude that OOP is bad based on that.

I'm seeing a lot of comments talk about inefficiencies versus collected data. Common points on either; on one hand OOP gathers your data into one spot, on the other it's inefficient and gets misused(often). Is this truly all there is to the contention? 'Self'-Organization vs Inefficiency? Or am I missing something major?

I'm sure there are some things that benefit from consequent uses of OO. Mostly projects with lots of related, but slightly different things to store and do. Programming a GUI certainly profits. But there is little point of creating an OO layer between a SQL DB and your code. If you only have a few things to do storing your data in a module is probably a lot less work a easier to maintain.