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.
Comments
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.
I feel like a fool sledgehammer world entities into hierarchical taxonomies of interacting objects and coupling behavior with data.