3 ms·
>Composition makes code inherently more maintainable and easier to refactor. My understanding of composition comes from interfaces in C#. In my experience comp
by allovernow 7y ago
>Composition makes code inherently more maintainable and easier to refactor.
My understanding of composition comes from interfaces in C#. In my experience composition is actually more difficult to code and refactor, because it leads to bloat from repeated code as you cannot simply inherit. Refactoring then can become tedious as you may need to manually edit every repeated code block. Whereas with inheritance I define a function once and override it where necessary.
Am I misunderstanding something?
- vardump 7y agoComposition tends to lead to more code reuse. And to more code that's still usable in unpredictable future. Over time your whole inheritance model often turns out to be no longer viable, when the basic assumptions made years ago are no longer valid. Worse, because of all of the accumulated cruft, you might not even be able to change the shape of the monster.
- arwhatever 7y agoI don't see that composition should be cause for repeated code blocks.
- loopz 7y agoComposition should lead to clean components for reuse. You might need some extra references, but it is more explicit, static and flexible. Inheritance sounds great in theory, but is a hierarchical blind-alley, though usable for static designs that never change much.
- sseth 7y agoIn go, composition has a special feature where if you include another type anonymously in a struct, the methods of that type are automatically available for the struct as well. It is also possible to "override" these methods at the struct level and call the anonymous member directly. So you can get some of the conveniences of inheritance. The behaviour is of course different, because the composed member has no way of knowing the identity of the including struct.