4 ms·

> We need to use an inheritance based design for our types, > despite composition being a much easier alternative, because > after 5 years of codebase growth,

> We need to use an inheritance based design for our types, > despite composition being a much easier alternative, because > after 5 years of codebase growth, it will make our lives > easier. And a equally future-proofy statement: "We need to contort our code to avoid our implementation language's inheritance features to instead use composition because after 5 years of codebase growth it will make our lives easier" There's a reason why the GoF says "prefer composition over inheritance" and then spends half the book covering inheritance.

squirrelicus 8y ago
I admit being confused about this one. Composition or inheritance isn't harder or more work, and neither provides velocity or maintainability benefits. The argument is about how to model complex behavior -- they have tradeoffs in duplication and statefulness. And you can mix both in the same code base with ease. Here's another one though. We need to use Promises despite callbacks being trivially understandable and supported everywhere in arbitrary JavaScript versions because in 5 years everyone will probably always use Promises for everything.
- richardwhiuk 8y ago
  I think the real takeaway is that composition is much more likely to model the semantics you have, even though inheritance feels like it gives you better code re-use.
  - squirrelicus 8y ago
    I admit to being a composition bigot when green fielding some functionality, and I've never felt like code reuse was a thing either mattered for. I like composition because it's easier to create small testable component contracts. But I maintain plenty of inheritanace based code and, while it's less testable, it's... fine. Not really a big deal to use either or both. Edit: to be clear, when I hear "code reuse", I think "using a component outside its original intent". Composition does impose some duplication sometimes, but it's braindead plumbing code, not buggy logic code, that gets duplicated. I generally think that cost is worth it to gain more statelessness. Hence my greenfield bigotry
    - btschaegg 8y ago
      > But I maintain plenty of inheritanace based code and, while it's less testable, it's... fine. I'd wager that it's rather good code then. There's also the inheritance-based code that isn't though, which slowly is driving me to the conclusion that "unsupervised" inheritance is some sort of petri dish for cthulhu-esque architectures. That doesn't mean inheritance is bad, per se -- just that we should stop and think much more about using it. Composability, on the other hand, isn't nearly as "invasive" since the whole point of it is the interaction of uncoupled things. This somehow reminds me of the promise of fusion vs. fission energy, where it's argued that in fusion you don't have to constantly prevent your reactor from exploding... :)
    - pvg 8y ago
      I like composition because it's easier to create small testable component contracts. You don't need testability or 'greenfielding' for this. 'Design by contract', as you mention, is a useful way to think about this, without attaching value judgments to composition or inheritance. Inheritance is a much stronger and therefore burdensome contract. It's much less likely bits of your model can really adhere to it. The advice to lean towards composition is a function of that - few models can meet that high bar.
      - squirrelicus 8y ago
        Right. Inheritance implies contracts that include behavior, composition implies contracts that don't. I talk of greenfielding because it's rare that the inheritance alone holds a codebase back so much that it needs to be rewritten. But code I originate is always composition based
pvg 8y ago
then spends half the book covering inheritance Does it really? The bulk of the patterns are about composition and delegation which is why wags using languages less restrictive than C++ have been able to do things like show 47819.73 patterns are variants of one or two things.

squirrelicus 8y ago

I admit being confused about this one. Composition or inheritance isn't harder or more work, and neither provides velocity or maintainability benefits. The argument is about how to model complex behavior -- they have tradeoffs in duplication and statefulness. And you can mix both in the same code base with ease. Here's another one though. We need to use Promises despite callbacks being trivially understandable and supported everywhere in arbitrary JavaScript versions because in 5 years everyone will probably always use Promises for everything.

richardwhiuk 8y ago
I think the real takeaway is that composition is much more likely to model the semantics you have, even though inheritance feels like it gives you better code re-use.
- squirrelicus 8y ago
  I admit to being a composition bigot when green fielding some functionality, and I've never felt like code reuse was a thing either mattered for. I like composition because it's easier to create small testable component contracts. But I maintain plenty of inheritanace based code and, while it's less testable, it's... fine. Not really a big deal to use either or both. Edit: to be clear, when I hear "code reuse", I think "using a component outside its original intent". Composition does impose some duplication sometimes, but it's braindead plumbing code, not buggy logic code, that gets duplicated. I generally think that cost is worth it to gain more statelessness. Hence my greenfield bigotry
  - btschaegg 8y ago
    > But I maintain plenty of inheritanace based code and, while it's less testable, it's... fine. I'd wager that it's rather good code then. There's also the inheritance-based code that isn't though, which slowly is driving me to the conclusion that "unsupervised" inheritance is some sort of petri dish for cthulhu-esque architectures. That doesn't mean inheritance is bad, per se -- just that we should stop and think much more about using it. Composability, on the other hand, isn't nearly as "invasive" since the whole point of it is the interaction of uncoupled things. This somehow reminds me of the promise of fusion vs. fission energy, where it's argued that in fusion you don't have to constantly prevent your reactor from exploding... :)
  - pvg 8y ago
    I like composition because it's easier to create small testable component contracts. You don't need testability or 'greenfielding' for this. 'Design by contract', as you mention, is a useful way to think about this, without attaching value judgments to composition or inheritance. Inheritance is a much stronger and therefore burdensome contract. It's much less likely bits of your model can really adhere to it. The advice to lean towards composition is a function of that - few models can meet that high bar.
    - squirrelicus 8y ago
      Right. Inheritance implies contracts that include behavior, composition implies contracts that don't. I talk of greenfielding because it's rare that the inheritance alone holds a codebase back so much that it needs to be rewritten. But code I originate is always composition based

pvg 8y ago

then spends half the book covering inheritance Does it really? The bulk of the patterns are about composition and delegation which is why wags using languages less restrictive than C++ have been able to do things like show 47819.73 patterns are variants of one or two things.