[wredcoll]

It's all pretty solid except for the part about OO.

Inheritance almost never works in "the real world" but I find being able to tie functions to the data they're expected to work on to be pretty helpful.

It's sort of like typing, really, functionX can only take FooBar variables vs making methodX on class FooBar.

Like everything else you can "do it wrong" and you shouldn't be a slave to any particular software ideology.

[parpfish]

i've been beating the drum for a long time that we teach OO programming wrong.

we always start with inheritance (Car is subtype of Vehicle; Cat is subtype of Animal).

we need to teach encapsulation as the primary use for OO.

ime, the most effective way of using "OO" in practice is that you define data classes for different entities and then affix a few fancy constructors that let you build entities out of other entities. inheritance rarely gets used.

[stavros]

This is my experience as well. I use encapsulation so often that to me it seems that that's the "point" of OOP, whereas inheritance I use extremely rarely.

[1718627440]

I think the reason for this is, that encapsulation is not at all specific to OOP, that was already common before. What OOP adds really is inheritance and RTTI. Even polymorphism was already standard.

[makeitdouble]

But then the function x data mapping isn't 1 to 1 in most cases, which is often why inheritance is used.

IMHO sperating data formats and functions works decently enough, interface/protocol/duck typing are more elegant than OO classes.

As a real world image, a barcode scanner could be applied to anything that has a barcode, regardless of what that thing is. And I'd wager 99% of what we're trying to do fits that mold. When authentifying a user, the things that matter will be wether it's a legitimate call, and whether the user is valid. Forcing that logic I to classes or filtering by use type quicky becomes noise IMHO.

[1dom]

I came to the comments to try find a similar sentiment. I agree wholeheartedly with the author on everything apart from the bit about OO, where I feel the same as you.

What's the deal with this? I'm not an OO evangelist at all, but I often find myself using objects like you describe: as a mechanism to group related functions and data.

I feel there are people who see OO like a philosophy on how to architect stuff, and from that perspective, the idea of a "purely OO system" is perhaps a little unwieldy.

But from the perspective of OO as a low level tool to help group stuff in programming, as part of some other non-pure-OO system - it works really well and makes a lot of sense for me. I've often done this in environments around people who are outspoken anti-OO who either haven't noticed or haven't complained.

Am I a bad person, are you like me, are we idiots somehow?

[nxrabl]

I think the specific trap the author is arguing against is where you try to make your classes model 1-1 some external domain model without tailoring them only to the functionally that your specific application needs. If you’re writing a FooClass, it’s easy to get caught up in giving it everything a Foo would have, even if you won’t actually use it.

[palata]

I feel like people who say "OO is never right" don't understand how to use it properly. Applies to other concepts as well, of course.

There are tools, and we as professional are expected to use them when they make sense. That's all. If you use a tool badly, don't blame the tool.

[RHSeeger]

> Inheritance almost never works in "the real world"

Inheritance works just fine in the real world. It's just not the only tool in the box, and many times other tools work better. But, especially when limited to shallow hierarchies, it's very useful.