Live data from Hacker News

Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

mail-archive.com

11–20 of 177 posts

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#11
post #7
post #5

I'm a game dev and usually program in C#. I love C# and honestly some features of OO (like objects and classes) are great for programming games. But inheritance is just a shit feature imo. Situations where it would be beneficial are extremely rare . I generally just pretend it doesnt exist. There are much better alternatives to it for most situations (eg. composition, build a class from other smaller classes that do…

Inheritance is just a total mess. Overriding a method, especially a non-abstract one, feels more like monkeypatching. It feels unsafe, it's not clear if I should do it, etc. A lot of Apple APIs mark which methods should be overridden and which shouldn't be. It just generally feels like a crappy approach. Languages with deep inheritance trees like Ruby and Smalltalk and even Objective-C are also extremely difficult to…

The user you responded to uses C#, you can't override arbitrary methods there. Only methods explicity declared as virtual can be overriden, so this is different than many other OO languages.

I think this is also the better approach, making inheritance something you have to explicitly design for instead of a way to monkeypatch almost everything.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#12

I completely agree that "good design"/"bad design" depends on the problems we're trying to solve, rather than some abstract property of the entities involved (i.e. whether "Car" should extend "Vehicle" or not, and whether those classes should even exist, cannot be answered without knowing what we're trying to accomplish). The suggestion of GUI widgets is certainly better and more concrete; although it's skating dange…

Much agreement on this. It's concrete, visible and has behaviors that work well (click, resize, draw etc.) as well as providing a good entry into the thought process when designing modern user interfaces with components.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#14
post #10

> In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus I wish someone had told me this when I first started coding. I wasted so much time building pointless hierarchies based on ontology rather than DRY.

DRY is also not the goal.

It's not a million miles from it though. If you start from DRY as an approach to OO design you'll produce something vaguely reasonable and be close enough to where you want to be that you can learn the differences.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#15
post #5

I'm a game dev and usually program in C#. I love C# and honestly some features of OO (like objects and classes) are great for programming games. But inheritance is just a shit feature imo. Situations where it would be beneficial are extremely rare . I generally just pretend it doesnt exist. There are much better alternatives to it for most situations (eg. composition, build a class from other smaller classes that do…

Once you've ditched hierarchy, haven't you entered "functional programming" territory? It's just types, structs/maps/dictionaries, factories, and modules/closures now, right?

You still have classes, even if you ignore inheritance entirely. And e.g. with the built-in dependency injection in ASP.NET it feels like you're subtly encouraged to use composition for many cases. This is still very much OO-style programming, inheritance is only one part of this.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#16
post #9

Entity-Component-System is so much nicer paradigm than any hierarchy. I wonder why it's not used much outside of gamedev.

I would have agreed with this whole-heartedly when I first started using ECS. It has its own difficulties though.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#17
post #7

Earlier quoted context omitted.

Inheritance is just a total mess. Overriding a method, especially a non-abstract one, feels more like monkeypatching. It feels unsafe, it's not clear if I should do it, etc. A lot of Apple APIs mark which methods should be overridden and which shouldn't be. It just generally feels like a crappy approach. Languages with deep inheritance trees like Ruby and Smalltalk and even Objective-C are also extremely difficult to…

The user you responded to uses C#, you can't override arbitrary methods there. Only methods explicity declared as virtual can be overriden, so this is different than many other OO languages. I think this is also the better approach, making inheritance something you have to explicitly design for instead of a way to monkeypatch almost everything.

> Only methods explicity declared as virtual can be overriden

You can with "new", no?

    public class Foo
    {
        public void Say() { Console.WriteLine("Foo!"); }
        public void Think() { Console.WriteLine("I;m thinkin about thos beans");
    }

    public class Bar : Foo
    {
        new public void Say() { Console.WriteLine("Actually, Bar!"); }
    }

So with Bar we have inherited Think(), but have overridden Say(). Ok technically the MSDN docs will say that we've "hidden" the inherited method Say(), but the effect here is that we've overridden something not marked "virtual"

edit: Oops yeah I'm talking rubbish, see replies for more info :D

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#18
post #5

I'm a game dev and usually program in C#. I love C# and honestly some features of OO (like objects and classes) are great for programming games. But inheritance is just a shit feature imo. Situations where it would be beneficial are extremely rare . I generally just pretend it doesnt exist. There are much better alternatives to it for most situations (eg. composition, build a class from other smaller classes that do…

Once you've ditched hierarchy, haven't you entered "functional programming" territory? It's just types, structs/maps/dictionaries, factories, and modules/closures now, right?

You've still got the concept of data hiding and an object lifecycle, I think. You're right in functional programming we often operate in quite a similar way to "objects without inheritance" - your module has an internal data structure, creates it at some point, manipulates it through a series of module functions. of course in functional you are usually not usually mutating directly.

Re: Goodbye, shitty Car extends Vehicle object-orientation tutorial (2011)

#20
After many years of OOP, I'm not sure if we gained anything from OOP, and if it wasn't a solution in search for a problem.

At first I was enthusiastic. Then I've realized that there might be better ways to solve problems than trying to fit everything in a "everything is an object" mentality.

OOP can lead to overly complex code, uneeeded abstractions and design patterns thrown on top of each other for no good reason.

There was a thinking that using objects you can model or imitate real life, but that is silly. And of course, programming doesn't deal with real life, but with bytes and instructions, data and actions performed on the data.

I still use OOP because most of the industry demands it, but when I can, I try to use a data oriented and a bit of a functional approach, even if I am using an OOP language.

Post reply on HN