
Object-Oriented Programming is Bad - jbeja
https://www.youtube.com/watch?v=QM1iUe6IofM&lc=z12hw314zrvkxxqol04cjrdwhsvjzz4q4kk0k
======
PhilWright
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.

~~~
EvanPlaice
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.

------
kristianp
Related non-video content:

[https://medium.com/@brianwill/object-oriented-
programming-a-...](https://medium.com/@brianwill/object-oriented-programming-
a-personal-disaster-1b044c2383ab#.k2httrx40)

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

(1) Hence this kind of thing
[http://stackoverflow.com/questions/10313128/java-generics-
co...](http://stackoverflow.com/questions/10313128/java-generics-compatible-
service-subclass) .

(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).

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

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

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

