4 ms·

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 composi

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

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