The title of the post is patent nonsense, so much so that I cannot even be bothered to watch the linked video.
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.
That's perfectly fine. Nobody is forcing you to not use OOP.
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.
Wow. So many aspects that I've attempted (and failed) to communicate to OOP devs in a clear, understandable presentation format.
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.
Ridiculous clickbait.
'the most important programming video you will ever watch', 'An explanation of why you should favor procedural programming over Object-Oriented Programming (OOP).'
Yeah right.
As if the last 30+ years of software development never happened.
I found the video was well presented, and the speaker spoke very well. The argument starts at around 18m20s after some background.
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.
(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 agree the headline is a bit "over the top" but it does grab you're attention.
The Video is actually extremely well done and very interesting - odd to me how some commentators feel justified to publish a disparaging opinion on this, when they haven't botyered to actually watch it!
I've never been that enamoured with the whole oop religion, but was always puzzeled as to how come it's beeen so succesful, if it's not that great?
This video finally solves that puzzle for me with a very compelling explanation for this.
I was intrigued by the presenter so had a look at some of his othe work, the guy is a bone fide programming genius, his knowledge is incredibly vast, this for me supports his credibility and his opinions.
9 comments
[ 3.7 ms ] story [ 34.7 ms ] threadI 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-...
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.
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).