4 ms·

I had the same thought when I saw that. There seems to be a trend to seal and lock down classes preventing any kind of extension. It sort of misses one of the

I had the same thought when I saw that. There seems to be a trend to seal and lock down classes preventing any kind of extension. It sort of misses one of the main benefits of OOP and I know what I'm doing.

scarface74 8y ago
Instead of my rehashing the old arguments about inheritance.... http://developer-interview.com/p/oop-ood/what-are-advantages-of-composition-and-aggregation-over-inheritance-14 http://developer-interview.com/p/oop-ood/what-are-advantages...
- wvenable 8y ago
  I understand the argument for composition-of-inheritance but they rarely apply when you actually need to do it. Often it's to reach in and fix a bug or enhance the behaviour of an existing component. You simply can't do that with composition. Without inheritance (if the class is sealed) I often end up having to re-write the entire component or simply accept my fate. So that is a lose-lose situation.
  - scarface74 8y ago
    That's where delegation comes in. You wrap each public method of Foo in another class call MyFoo and then fix the one method you care about. With C# and R# it's a simple matter of: Create a new class Create a private variable: private Foo _foo Click on _foo Resharper menu -> Generate Code -> create Delegating members.
    - wvenable 8y ago
      But you can't pass that into places that accept Foo because MyFoo isn't of the type Foo so that's a non-starter is most cases. Secondly this code generation solution is just re-implementing inheritance again poorly and with the above mentioned limitation. I fail to see how code generating a proxy is any way better than (or significantly different from) inheritance.
      - scarface74 8y ago
        Hopefully the code was written to depend on interfaces and not hard coded types.
        wvenable 8y ago
        So if you implement an interface and then use code generation to create proxy from a "parent class", congratulations you just reinvented inheritance. What's the difference?
- wvenable 8y ago
  That's a terrible article. > There is principle, which sounds like "favor object composition over class inheritance". This is begging the question, isn't it? Why favor object composition over inheritance? The qualification here that's missing is "for code re-use". If your goal is simply to re-use code then you should favor composition. But if you're actually modeling an is-a relationship or trying to modify the behavior of a base class then that's not just for code re-use. This subtly seems to have been lost. It's much easier to religiously ban all inheritance than to simply use it appropriately. > In most cases "HAS-A" relationship is more semantically correct than "IS-A" relationship between classes. In most, but not all cases. You will find that in most cases of inheritance in frameworks, for example, follow the is-a relationship perfectly. And you'll find most of time composition is used for has-a relationships. It's an error to mix this up but that's not the fault of inheritance. For example, in my own software I inherit from the database context class to provide a host of features beyond what the framework provides. My context is a database context. > Composition is more flexible than inheritance. If you need that flexibility, great. But I don't see why having more flexibility is automatically good for the correctness of the program. If X is always implemented by Y, that's much easier to reason about. > Inheritance breaks encapsulation. I don't see how that's true. Your base class exposes what it wants to potential child classes so encapsulation is preserved. There are some languages that provide no limits (no protected/private/virtual/etc) but then those don't provide any encapsulation in any other situation either. > A design based on object composition usually will have less classes. Says who? What's the research behind this? I assume most projects have a mix of inheritance and composition as needed. > It is possible to implement "multiple inheritance" in languages which do not support it by composing multiple objects into one. That's not multiple inheritance -- it's just composing multiple objects using some kind of proxy. There is a difference. > There is no conflict between methods/properties names, which might occur with inheritance. Ok, that's a fair point.
hermitdev 8y ago
Inheritance is also one of the most tight forms of coupling, which should be avoided. One is better off to use composition than inheritance.
keithnz 8y ago
As a consumer of library software, yes, you know what you are doing and you know how you want to override things. That is true. But the advice is more about how to create stable libraries that can change over time and making sure the public surface area and extensibility points are created deliberately and can be maintained. It means the lib developer can release their software knowing that he didn't make any breaking changes to the public surface area of the library. The problem is, some libs are not well maintained, and not that well designed, and you (the generic "you" ) are happy to deal with breaking changes if and when they come along on version upgrades. It can be frustrating if they essentially locked it all down without much thought. But in general, I think the sealed by default is the better advice. You can do cunning ( evil ) things to get around it.

scarface74 8y ago

Instead of my rehashing the old arguments about inheritance.... http://developer-interview.com/p/oop-ood/what-are-advantages-of-composition-and-aggregation-over-inheritance-14 http://developer-interview.com/p/oop-ood/what-are-advantages...

wvenable 8y ago
I understand the argument for composition-of-inheritance but they rarely apply when you actually need to do it. Often it's to reach in and fix a bug or enhance the behaviour of an existing component. You simply can't do that with composition. Without inheritance (if the class is sealed) I often end up having to re-write the entire component or simply accept my fate. So that is a lose-lose situation.
- scarface74 8y ago
  That's where delegation comes in. You wrap each public method of Foo in another class call MyFoo and then fix the one method you care about. With C# and R# it's a simple matter of: Create a new class Create a private variable: private Foo _foo Click on _foo Resharper menu -> Generate Code -> create Delegating members.
  - wvenable 8y ago
    But you can't pass that into places that accept Foo because MyFoo isn't of the type Foo so that's a non-starter is most cases. Secondly this code generation solution is just re-implementing inheritance again poorly and with the above mentioned limitation. I fail to see how code generating a proxy is any way better than (or significantly different from) inheritance.
    - scarface74 8y ago
      Hopefully the code was written to depend on interfaces and not hard coded types.
      - wvenable 8y ago
        So if you implement an interface and then use code generation to create proxy from a "parent class", congratulations you just reinvented inheritance. What's the difference?
wvenable 8y ago
That's a terrible article. > There is principle, which sounds like "favor object composition over class inheritance". This is begging the question, isn't it? Why favor object composition over inheritance? The qualification here that's missing is "for code re-use". If your goal is simply to re-use code then you should favor composition. But if you're actually modeling an is-a relationship or trying to modify the behavior of a base class then that's not just for code re-use. This subtly seems to have been lost. It's much easier to religiously ban all inheritance than to simply use it appropriately. > In most cases "HAS-A" relationship is more semantically correct than "IS-A" relationship between classes. In most, but not all cases. You will find that in most cases of inheritance in frameworks, for example, follow the is-a relationship perfectly. And you'll find most of time composition is used for has-a relationships. It's an error to mix this up but that's not the fault of inheritance. For example, in my own software I inherit from the database context class to provide a host of features beyond what the framework provides. My context is a database context. > Composition is more flexible than inheritance. If you need that flexibility, great. But I don't see why having more flexibility is automatically good for the correctness of the program. If X is always implemented by Y, that's much easier to reason about. > Inheritance breaks encapsulation. I don't see how that's true. Your base class exposes what it wants to potential child classes so encapsulation is preserved. There are some languages that provide no limits (no protected/private/virtual/etc) but then those don't provide any encapsulation in any other situation either. > A design based on object composition usually will have less classes. Says who? What's the research behind this? I assume most projects have a mix of inheritance and composition as needed. > It is possible to implement "multiple inheritance" in languages which do not support it by composing multiple objects into one. That's not multiple inheritance -- it's just composing multiple objects using some kind of proxy. There is a difference. > There is no conflict between methods/properties names, which might occur with inheritance. Ok, that's a fair point.

hermitdev 8y ago

Inheritance is also one of the most tight forms of coupling, which should be avoided. One is better off to use composition than inheritance.

keithnz 8y ago

As a consumer of library software, yes, you know what you are doing and you know how you want to override things. That is true. But the advice is more about how to create stable libraries that can change over time and making sure the public surface area and extensibility points are created deliberately and can be maintained. It means the lib developer can release their software knowing that he didn't make any breaking changes to the public surface area of the library. The problem is, some libs are not well maintained, and not that well designed, and you (the generic "you" ) are happy to deal with breaking changes if and when they come along on version upgrades. It can be frustrating if they essentially locked it all down without much thought. But in general, I think the sealed by default is the better advice. You can do cunning ( evil ) things to get around it.