I have written software for almost 20 years that is OO based. I have worked on lots of successful projects that made companies lots of money and served countless end users well. Sure, there have been failed projects along the way as well.
One thing you realise after many years in the industry is that the quality of the developers on a team is more important than the paradigm they are using. I've worked with poor developers that would have written crap software in whatever language/paradigm/environment they used. I have also met some amazing developers that could develop great software in the worst language/environment imaginable.
So saying that OO is intrinsically bad is simple nonsense and frankly childish.
The video just outlines the fundamental weaknesses of using OOP as the end-all-be-all solution to managing encapsulation. Namely, that it creates as many (if not more) problems than it's superficially purported to solve.
IMHO, OOP is a useful design pattern for some specific classes of problems. Treating it as a cure-all ideology is self-defeating.
There's a huge disconnect between creating large applications using OOP and maintaining them over the long-term. In the latter case, abstractions that get baked into an OOP-only architecture will eventually start to leak in dangerous and unexpected ways as the needs of business change over time. Short-term savings in the form of strict adherence to DRY and SRP can (and will) eventually accrue as technical debt over time.
Common conventions such as design patterns, DI, and TDD minimize the negative impact but they're indicative of a bigger problem.
With that said. I agree, the title is dumb and clearly detracts from the underlying message.
https://medium.com/@brianwill/object-oriented-programming-a-...
Having recently started working on an ASP.net MVC project, I'm in agreement with this video that there has to be a better way to create applications. So many classes and so many services, controllers, dtos (1) and interfaces have to be written. I think the video is railing against the Java and c# style where everything has to be a class, and I agree with that. Comparing Rails with the GoFness (2) of a Java or c# web application, you can see that there are better abstractions that can be used than just creating structures of objects to solve every problem. Programming languages or tools that allow more dynamic constructs or higher level static constructs or code generation are better than just making the developer build many classes to fit into an OO framework.
I know this kind of thing has been written before, but I wanted to write in support of this video's viewpoint.
(1) Hence this kind of thing http://stackoverflow.com/questions/10313128/java-generics-co... .
(2) GoFNess - Design Patterns: Elements of Reusable Object-Oriented Software is a software engineering book. The authors are often referred to as the Gang of Four (GoF).
I've been working with Angular2 a lot lately and it's has been painfully obvious how much effort they've put in to make the framework appeal to devs with an OOP mindset.
God object? Yep, they use a directed acyclic graph for to manage dirty checking. Global state management via singletons? See services. Factory pattern? See providers. Static typing with type coercion, interfaces, and class based inheritance? See Typescript. Etc...
They have effectively reimplemented every single common design pattern used in OOP, in Javascript. A language that fundamentally doesn't require OOP patterns to provide the same degree of flexibility and functionality.
It gets really 'weird' when they encounter aspects that can't effectively be defined using OOP alone, such as async data binding. Instead they use functional programming patterns such as observables/promises.
Personally, I prefer to write NG2 code in ES6. Types in Javascript are nothing more than window dressing to make the transition less painful for OOP devs and enable better autocompletion support in IDEs.
In practice, type checking during runtime will have to be disabled because it causes a significant negative impact on performance.
TBH. It feels kinda 'dirty'. Like I'm some OOP addict (ie C# dev in the past) who is dabbling with old habits.
