Hacker News Reader

Comment by kentonv | Hacker News Reader

The idea that OOP is a fad and that everyone is abandoning it is... absurd. I think that the author thinks OOP means ObjectListenerBuilderProviderFactoryAdpterImpls and repeated use of words defined by Gamma et al. Actually, OOP is just the practice of encapsulation and abstraction, and the avoidance of globals/singletons* in favor of infinitely instantiable instances. These are not a fad, they are necessary components of all large-scale software.

The Linux kernel, which is entirely written in C, is a fine example of object-oriented programming. File descriptors are object references. The filesystem is a beautiful heirarchy of polymorphic nodes. There simply is no non-OOP way to implement these things.

* I cannot mention singletons without linking this essay of mine, even though I'm somewhat embarrassed that I never found time to fill in the rest of the site: http://www.object-oriented-security.org/lets-argue/singleton...

View on HN

> There simply is no non-OOP way to implement these things.

Yes there is. You can implement them as an endofunctor.

> There simply is no non-OOP way to implement these things.

Depending on your specific definition of OOP.

I suspect what the author is talking about is the high level of coupling that occurred in a looooot of 90's/early 2000's codebases. It was a time of learning for many many people, but our industry as a whole, and the C++ community specifically, has learned a lot from those mistakes.

There is an appropriate application of almost any tool, what's wrong is the hype behind certain ones. By abandoning the fad I don't mean that now everybody will never use OO again, but that OO had become the -default- paradigm for -everything- (even the only one that gets taught nowadays), which is completely utterly bullshit.

- Angelo from c0de517e

Neither debug logging nor any other unique system resource has to be passed as a singleton. All that is needed is the appropriate ApplicationContext structure to be passed to each object that needs these facilities, and the ApplicationContext will contain all the singleton instances that are required.

Yes, you can do that, it just gets tiring, because now you have a boilerplate parameter being passed everywhere. It really has to be passed everywhere, because you never want to get stuck without the ability to debug some function just because you didn't pass in the debug logger object.

The environment pattern effectively makes this context implicit.

The solution is - more objects wrapping more objects. I can already imagine people doing exactly that.

Dependency injection is the name of the game right? That's what videos on youtube are advocating...

But it's also a pain to pass everything that is needed down to functions, so let's stuff all the global state in a class and pass that class down!

I hope I just didn't get the sarcasm, really.

Reply on news.ycombinator.com