Comparing Object Composition Vs. Class Inheritance

Composition and inheritance are two popular techniques for establishing relationships between classes and objects. Here are a few reasons why you should use composition instead of inheritance.

.

#arjancodes #softwaredesign #python

[shiny_apricot]

Your videos are highly underrated for a software engineer

[michaelbroyles]

Love this! This concept really stepped of my code.

[ubbholeswar]

Could you please elaborate with more examples for this concept

[estelisarva]

I think composition is just DI. Am I wrong? Please advise me. 😊

[darkengine]

Beyond the decoupling, I think inheritance does a poor job of modeling the real world if we're trying to design a flexible but intuitive architecture since it models "is-a" relationships to determine functionality available and that's not how the real world works.

It's not because a biped *is* a biped that it can walk; it can walk because it *has* functional legs (and some bipeds can't walk because their legs are missing or crippled). It's not because an airplane is a flying object that it can fly, it can fly because it has wings. And a duck can both fly and walk because it has both wings and legs. Composition just more accurately models the real world; the functionality something can perform is based on what it *has*, not what it *is*. Not only that, but what something has can change dynamically at runtime, which is also more representative of the real world. A human might have functional legs until being injured; now he has no legs, and composition provides that immediate and direct flexibility to add and remove components on the fly as well as querying what components are currently available for an entity.

This is a big reason besides decoupling (although this is fundamentally about decoupling) and also performance that gamedevs are moving away from using inheritance for their engines and instead alternatives like entity-component systems (which model more of a compositional "has-a" relationship: entities "have" components). That "is-a" relationship is too rigid and inflexible. A common example given is that an inheritance hierarchy which distinguishes plants from animals will quickly paint a game developer in a corner if he has to produce a fantasy game which, in the later stages of development (perhaps a DLC), now requires creating a creature that has the data and functionality of both an animal and a plant so that existing systems can process them both ways without being rewritten. Pure interfaces without inheritance hierarchies can mitigate that, but they're still far more rigid and inflexible than composition (ex: we can't add and remove interfaces on the fly).

[MCRuCr]

thats it, create lots of independent little hierarchies, each describing one singular concept. Then compose those into a larger system. Subclasses should revolve around different of the same concept, not extending that concept

[elysonpanolino]

Is injection always better than composition?