Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving Beyond the OOP Obsession

prog21.dadgum.com

Post reply on HN
Print view View original

41–50 of 72 posts

Re: Moving Beyond the OOP Obsession

#41

Post by jdmichal »

Nutmog wrote: post #6

What baffles me about OOP is that massive aspects of how to use it have changed, and that change happened after it gained popularity as a good technique. How could it have become popular when people were doing it wrong? The article mentions inheritance, but there's also heavy vs light classes. When I was taught OOP, an object knew how to do all the things to itself. It could draw itself on the screen, modify itself,…

There has definitely been continued learning of how to best use OOP, as with any programming paradigm. While they all existed individually before-hand, the SOLID principles as a collection weren't formalized until the 2000's. [0] For instance, "heavy" classes is likely a clear break of Single Responsibility and is probably also a break of Interface Segregation. I also can't recall ever seeing an introduction to inheritance that doesn't break the Liskov substitution principle -- sometimes subtly, but usually quite overtly.

I think the large issue with OOP education is that it is still being taught as a set of capabilities without the appropriate constraints (SOLID) that have been learned by engineers under fire.

[0] https://en.wikipedia.org/wiki/SOLID_%28object-oriented_desig...

Re: Moving Beyond the OOP Obsession

#42

Post by sklogic »

heartsucker wrote: post #19
sklogic wrote: post #14

A value, with a type. Nothing else. Stop highjacking everything into your OO religion. If you take everything of a value that originated elsewhere, there will be nothing left in the OOD.

> Stop highjacking everything into your OO religion. The parent to your post seemed to have a legitimate question, and you're being snarky. You could have left out everything after the first sentence or even explained what that means in practice.

It was a bad argument disguised as a "question". I rarely tolerate this sort of a discourse.

Re: Moving Beyond the OOP Obsession

#43

Post by dboreham »

The author seems to genuinely not know that this is the original motivation for C++ -- to provide syntactic sugar and additional type safety to the very techniques he describes, which were (and still are) widely used in C. It is as if I am reading a "Software The Onion". Hmm...checks date...

Re: Moving Beyond the OOP Obsession

#44

Post by sklogic »

exprx wrote: post #24
sklogic wrote: post #14

A value, with a type. Nothing else. Stop highjacking everything into your OO religion. If you take everything of a value that originated elsewhere, there will be nothing left in the OOD.

A value with a type is an object? What else do we need? “Methods”? Why? I very strongly support the proposed Unified call syntax.

The word "object" comes loaded with a shit ton of ideology. There is absolutely no need to rename the long established terms to simply please a bunch of religious zealots.

Re: Moving Beyond the OOP Obsession

#45

Post by scomment »

Okaaaaaaay, so if we left everything what OOP gived us (properties^1, generics, lot of good patterns^2, lot of abstractions for generic things, like interface^3, events, higher level datastructures, delegates, namespaces, modules^4 etc.) then we get C? Omg, thank you Captian Obvious! Learn OOP first.

What a bullshit article.

1) C++ for OO example? Seriously, why??? Grab a modern language who have properties at least. Even Delphi had it!

2) IMHO without OO patterns OOP worth nothing

3) I know, you can do interfaces in C++ with pure virtual classes, but you miss the abstraction behind that.

4) Java JAR, .NET assemblies, no matter what they called.

Re: Moving Beyond the OOP Obsession

#46

Post by Retric »

seivan wrote: post #40
Retric wrote: post #39

Earlier quoted context omitted.

Let's suppose you want labels, text boxes, and buttons on a form. Now you can do this without OOP or making a huge chunk of form code, but OOP is a natural fit. Especially if we may want to add pictures or video in the future.

Are you saying all these outlets (labels, text box, buttons) are inheriting from a base FormObject that can be rendered? That would work without OOP. Make a FormRender component that manages that logic (being rendered in a form) and other components, one that manages a keyboard, other that can be clicked and handle hover, touch states, etc.

Sure, but routing get's complex in your solution. The point was OOP is a natural fit for collections of different types in some context ex:GUI, Simulation, etc. The classic OOP case is probably a MUD where OO code ends up being very straightforward.

IMO, the problem is it works really well in so many contexts that people end up trying to use it everywhere.

Re: Moving Beyond the OOP Obsession

#47

Post by scomment »

rlidwka wrote: post #33
sparkie wrote: post #3

I don't disagree with the author's sentiment about inheritance (or OOP in general), being used and taught wrongly, but I still think it's a necessary tool to have available. Without inheritance, as soon as you want to cast mixer to something else, you're either relying on binary wizardry by the compiler (reinterpret_cast. ie, undefined behaviour), or you need to break encapsulation to copy the fields over from one ob…

> Without inheritance, as soon as you want to cast mixer to something else, you're either relying on binary wizardry by the compiler Why would you want to cast mixer to something else? What real-life task does it solve? > If we assume we have both a hardware mixer and a soft mixer which both have the set volume method, we wan't polymorphism so we can treat them equally. Polymorphism isn't OOP feature. You can have ov…

> Why would you want to cast mixer to something else?

Did you ever heard about interfaces? You can have a IMixer interface, a Mixer baseclass and some concrete mixer classes depending on your task. Like null-mixer for mocking, software mixer for legacy computers, hardware mixer with GPU support, etc. Use your imagination, Luke!

Re: Moving Beyond the OOP Obsession

#48

Post by astrobe_ »

exprx wrote: post #12

>Now here's what this would look like in C++ without using objects: mixer_set_volume(m, 0.8); What is m, if not an object?

"Object" is such a generic term that one can call anything an object. However, in the OOP world, an entity is an object if it has been defined or created like an object in the language's syntax. So the answer to your question is: we don't know, show us its declaration.

But the truth is that one can write many different stories on this line. One can tell the OO story in which m is an object, one can tell the FP story in which m is an IOMonad, one can tell the procedural story in which m is a record.

All of these stories are more or less equally good if it's a single line of code. But on a whole program, some of them can be more or less believable at certain points. For instance, when the OOP story tells us that integers are objects and that "+" is a message to which integers answer by given the result of an addition, this part of the story can seem a little far-fetched for some people.

Is there such a thing as the "best story in the world"? Definitely not. There's not even a "my favourite story" for most people, but instead a "my favourite love story" and a "my favourite horror story", and so on. How does one come up with a favourite story? By reading stories.

Re: Moving Beyond the OOP Obsession

#49

Post by scomment »

seivan wrote: post #40
Retric wrote: post #39

Earlier quoted context omitted.

Let's suppose you want labels, text boxes, and buttons on a form. Now you can do this without OOP or making a huge chunk of form code, but OOP is a natural fit. Especially if we may want to add pictures or video in the future.

Are you saying all these outlets (labels, text box, buttons) are inheriting from a base FormObject that can be rendered? That would work without OOP. Make a FormRender component that manages that logic (being rendered in a form) and other components, one that manages a keyboard, other that can be clicked and handle hover, touch states, etc.

And you started slow reinvention of OOP!

Re: Moving Beyond the OOP Obsession

#50

Post by scomment »

sklogic wrote: post #14

A value, with a type. Nothing else. Stop highjacking everything into your OO religion. If you take everything of a value that originated elsewhere, there will be nothing left in the OOD.

Okay, now give me some collection like object, who can handle everything. No, don't use void*.

There are some benefits if everything is an object, like generics.

Post reply on HN