4 ms·

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 inheritanc

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 one thing)

the_other 4y ago
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?
- fabian2k 4y ago
  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.
- rkangel 4y ago
  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.
- everyone 4y ago
  The atomic element of code is the function. If I just religiously stick the fundamentals of good programming, tiny functions, avoid coupling, avoid duplication (within reason), then I am at least half way to having nice maintainable code already. Once I have all these really nice tiny functions, Its trivial to reorganise and replace them. Though I find classes also very useful, a class is mainly a bucket that you put functions into. Ideally a class is a black box that does one thing. All the functions needed to do that thing are in the class and also any relevant fields. Not being able to have fields in there would be counter productive. It's just so handy to have all the functions + fields that govern this one element of your game all in one place.. When you need to make changes everything relevant is one place, and that place also functions as a black box that the other elements dont know about. So to change one feature in the game u just change or replace that one class. Just looking at the functions, nice maintainable code would look identical in a functional or OO language. I think the big differences between functional and OO are actually not important. I could put functions in a class, or just together in the same file. Putting certain functions and fields into this same bucket is just a convenience and its intuitive to understand imo. Like I said in 6 months time when I have to change feature X I know where to look.
bowsamic 4y ago
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 learn how to use due to how much basic functionality of the object comes from far up the chain. Remember when Steve Jobs wanted people to make companies that just sell objects? Sounds like my worst nightmare. I don't see why Rust's dynamic traits, or just duck typing, aren't totally superior
- fabian2k 4y ago
  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.
  - smcl 4y ago
    > 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
    - fabian2k 4y ago
      Using new is still very different from using override, there are real differences in behaviour there. Though I never used "new", it's usually described as a really bad idea unless you know what you're doing, I never saw the need to use this.

the_other 4y ago

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?

fabian2k 4y ago
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.
rkangel 4y ago
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.
everyone 4y ago
The atomic element of code is the function. If I just religiously stick the fundamentals of good programming, tiny functions, avoid coupling, avoid duplication (within reason), then I am at least half way to having nice maintainable code already. Once I have all these really nice tiny functions, Its trivial to reorganise and replace them. Though I find classes also very useful, a class is mainly a bucket that you put functions into. Ideally a class is a black box that does one thing. All the functions needed to do that thing are in the class and also any relevant fields. Not being able to have fields in there would be counter productive. It's just so handy to have all the functions + fields that govern this one element of your game all in one place.. When you need to make changes everything relevant is one place, and that place also functions as a black box that the other elements dont know about. So to change one feature in the game u just change or replace that one class. Just looking at the functions, nice maintainable code would look identical in a functional or OO language. I think the big differences between functional and OO are actually not important. I could put functions in a class, or just together in the same file. Putting certain functions and fields into this same bucket is just a convenience and its intuitive to understand imo. Like I said in 6 months time when I have to change feature X I know where to look.

bowsamic 4y ago

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 learn how to use due to how much basic functionality of the object comes from far up the chain. Remember when Steve Jobs wanted people to make companies that just sell objects? Sounds like my worst nightmare. I don't see why Rust's dynamic traits, or just duck typing, aren't totally superior

fabian2k 4y ago
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.
- smcl 4y ago
  > 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
  - fabian2k 4y ago
    Using new is still very different from using override, there are real differences in behaviour there. Though I never used "new", it's usually described as a really bad idea unless you know what you're doing, I never saw the need to use this.