
Composition over Configuration - skellertor
https://johno.com/composition-over-configuration
======
Vanderson
I have recently been digging into composition as related to object oriented
programming.

Can someone summarize why this is better than say inheritance?

I can possibly understand the value of composition where you need a large team
to be able to constantly add and remove functionality to a code base with this
without having to mess with APIs override methods, etc...

But is there a fundamental benefit of composition over inheritance in ever
circumstance? (I've read a number of articles on this recently and I am not
understanding the benefits vs the complications it adds)

~~~
pseudoramble
Another reason is it can help make testing more simplified. Instead of having
to use a library to perform mocking or stubbing of specific functions within
the objects, you can pass in fake instances of objects that help exercise the
test properly. So instead of trying to mess around with the internals of an
inherited object structure, you just redefine the objects during testing to
meet your needs.

In other words, objects are composed of their dependent objects. I think this
is where the idea of dependency injection comes from (though I find dependency
injection frameworks complicated often, that's another story).

~~~
asimpletune
I can not more strongly endorse this reason.

Building abstractions around useful/loosely coupled ways of encapsulating
dependencies, as mentioned elsewhere in this thread "bottom up", is part of an
organic process that evolves into getting design right. A huge "lever" that
you can lean on in this process is being able to mock the things that you
want, while also being able to use the "real" versions of the things that you
want. This allows your code to pretty much always be testable and flexible.

It takes some practice, but once you get it your code grows so much better.

~~~
pseudoramble
> It takes some practice, but once you get it your code grows so much better.

It's true. I had a bit of a roundabout journey to getting this idea.

Studying CS, I learned a ton about implementation inheritance, and only a bit
about composition - enough to sort of answer a question about it, but not
really get the feeling. So overall I didn't use it much.

When I started working, I saw implementation inheritance used a ton and got
the impression that it really made things way too complex. There was more to
the complexity than just this of course (design patterns everywhere,
convoluted abstractions, strange monolith tools, etc) but it didn't help.

Later I started learning about FP, where composition is just second nature,
and frankly one of the main methods of abstraction you get. So learning how to
compose things came from functions.

Over the past few months I've come back to more OOP, and I've been using
composition a whole lot more. And it does make a huge difference, and I don't
think I've used any sort of inheritance for my own code at all at this point.

So yeah, I agree and it is a journey.

~~~
asimpletune
I love that description of your evolution and I’d say it was actually the same
for me.

------
de_watcher
Doesn't clearly explain what "configuration" he's talking about.

~~~
shusson
I think it's a frontend framework configuration, like enabling a gatsby
plugin[1]. Anyway it seems like comparing apples and oranges to me.

[1] -
[https://www.gatsbyjs.org/docs/plugins/](https://www.gatsbyjs.org/docs/plugins/)

------
cmwelsh
A monk asked Java master Kaimu: What is the “single-responsibility principle”?

Said Kaimu: That a class shall do exactly one thing, and do it completely.

The monk asked: How shall I decide this “one thing”?

Said Kaimu: The Fisherman does not build ships, or we would call him a
Shipwright.

The monk asked: Is there no room in your philosophy for interfaces? What if my
class can serve as a Fisherman, and a Shipwright and Sailor besides?

Said Kaimu: What would you name such a three-headed monster?

The monk replied: Shísho, after my uncle. He lives by the sea and does all
these things.

Said Kaimu: I would give your class Shísho three instance variables: a
Fisherman, a Shipwright, and a Sailor. Then Shísho may implement those
interfaces by delegation.

The monk replied: I speak of inheritance, yet you answer in composition. All
of my uncle is a Fisherman, not just his left foot. What use are objects, if
we do not faithfully model the world?

Said Kaimu: If I paint a fine shark upon this page, will you say, “Fine
shark!” or will you complain that it is flat and does not eat you?

The monk asked: But how are we to know when the flat shark is shark enough? Or
when our uncle should fish with his left foot?

Said Kaimu: Learning how is our “single reponsibility”.

\- “Flat Shark”

[http://thecodelesscode.com/case/175](http://thecodelesscode.com/case/175)

------
gambler
If your system doesn't have anything to gracefully handle inter-component
communication without coding custom adapters and introducing new dependencies,
all your "reusable" components will become a legacy mess in 2-5 years.

------
andrewstuart2
Configuration === composition, IMO.

Composition is just bringing together a bunch of objects to form something
that does more.

Configuration is just bringing together a bunch of primitives, perhaps
structured, to form something that does more.

