>Why would we assume that? If the objects are entirely distinct, why are you combining them together into one class at all? That doesn't make any sense. Let distinct types be distinct. Let consumers of those types combine them however they like.
Human = torso, legs, arms. Three distinct objects combine into one thing. A human by definition is the union of these things. It's fundamental. It's just your bias is trying to see it as something else.
>So now the objects have 90% of their properties shared. That's different from what you were saying earlier. But moving on...
So? I can talk about multiple things right? This is allowed in life right? Did i break the law here?
>The composition answer is similar to the inheritance answer. Take the common parts and extract them out into a self contained type. Use that type everywhere you need it - eg by including it in both A and B.
Composition is the same thing. But it's saying instead of overriding duplicate properties, Clone the duplicate property. That's it. And it uses nesting to achieve this. This arbitrary rule isn't more fundamental then overriding the duplicate property.
>Via composition, you do it like this:
Why don't you take a look at my examples again. You are either not able to comprehend or you didn't read it. I literally said the same thing:
B = {a: A, e}
The above a complete dupe of what I wrote.
B = {a, b, c , d, e}
Just nested. Which I brought up:
B = {{a, b, c, d}, e}
Is it not? Please read my response replying with stuff like this. Read it thoroughly.
>And that's an incredibly damning criticism, because complexity is an absolute killer.
Not exactly it's not that straightforward. Because inheritance minimizes code copying. It reuses code in the most efficient way possible. So actually lines of code and duplicate code actually goes down. So complexity in one area falls and rises in another area.
Our brains are biased towards handling complexity of duplicate code better then tightly coupled code.