3 ms·

Class hierarchies are not a desirable feature of object-oriented languages, they're an unfortunate side effect of their historical development. (For example, ea

Class hierarchies are not a desirable feature of object-oriented languages, they're an unfortunate side effect of their historical development. (For example, early versions of Java did not actually have the interface keyword at all.) There are several very good reasons that the inherited wisdom about OOP includes such phrases as "prefer composition and delegation over inheritance". There are some cases where class hierarchies are actually good, but they're far rarer than most would suspect. The Liskov Substitution Principle is less of a guide as to how to use inheritance as much as it is a guide as to when you should not be using inheritance at all. And to address your point: the only time objects with class hierarchy and subclases should be accepted as arguments to methods is precisely when the LSP holds. Otherwise, you're gonna have a bad time.

martijn_himself 7y ago
These are all valid points and it shows my lack of understanding (same with the other comments), even though I use C# on a semi-regular basis I have a lot to learn! I don't envy any newcomers to the language though, there is so much to take in.
- 1propionyl 7y ago
  My general advice to anyone working with C# is the same advice given by the authors of Smalltalk to developers. 1) Always prefer composition and delegation to inheritance. 2) Always prefer interface inheritance to implementation inheritance even if in the short term it results in code clones. 3) If you intend to have multiple subclasses that adhere to the Liskov Substitution Principle, it is always better to have IFoo and X implements IFoo, Y implements IFoo... than it is to have abstract class Foo where X, Y extend Foo. You can still do that, behind the scenes, but your public interface should whenever possible be nearly entirely interfaces and concrete classes. 4) Inheriting the body/behavior of methods is seductive but ultimately only a poor excuse for not delegating that will create maintenance headaches down the line.

martijn_himself 7y ago

These are all valid points and it shows my lack of understanding (same with the other comments), even though I use C# on a semi-regular basis I have a lot to learn! I don't envy any newcomers to the language though, there is so much to take in.

1propionyl 7y ago
My general advice to anyone working with C# is the same advice given by the authors of Smalltalk to developers. 1) Always prefer composition and delegation to inheritance. 2) Always prefer interface inheritance to implementation inheritance even if in the short term it results in code clones. 3) If you intend to have multiple subclasses that adhere to the Liskov Substitution Principle, it is always better to have IFoo and X implements IFoo, Y implements IFoo... than it is to have abstract class Foo where X, Y extend Foo. You can still do that, behind the scenes, but your public interface should whenever possible be nearly entirely interfaces and concrete classes. 4) Inheriting the body/behavior of methods is seductive but ultimately only a poor excuse for not delegating that will create maintenance headaches down the line.