>>>>At assemble time - in the kettle production line - they work with physical modules - they don't need the blueprints. Likewise in code, we can ship external modules that will be combined when needed at execution time. That is a godlike power only programmers have, and few ever seem to use it.
>>>
>>>I'm not sure cohesion is the right term. Adhesion means "sticks to other things", cohesion then means "sticks to itself". Which means in this case cohesion is bad, you don't want your class to contain everything it may need - you want it to reuse parts already available. Where we spell reuse all uppercase until the apprentice turns blue in the face.
>>
>>Wrong. https://en.wikipedia.org/wiki/Cohesion_(computer_science)
>>
>>A thing must be internally cohesive. It must have loose connections to other things. Even if all of those things make for a single thing, it still has nothing to do with where the blueprints are stored at design time.
>>
>>
>>>
>>>True, sticking (pardon the pun) to reusability may make you stop and think things over a few times before even thinking of the name of the thing you want to make, just making sure what (and how) it should use that already exists, and what other uses may come up and where to leave those potentially loose connectors available. Even in the short term it pays off - every such pause, when you basically plan for the connections between your future objects and how will they play together, saves you hours of coding. It's invisible, that saved time, but hey, you're the programmer god, you can always switch to "there's never time enough to do it right, but there's always time to do it twice" :).
>>>
>>>IOW, we've always done this, and now you come and tell us it's called sex cohesion...
>
>As operational definitions and semantics have been observed to shift over time, I'd subsume the example under the "prefer composition over inheritance" hint, which is underused in vfp and sometimes over- or misused in Python, Javascript or C++.
>The typical Java pattern of dynamically aggregated helper objects *coupled with default methods in interfaces* IMO still one of the easiest patterns to follow without doubt of workings of diamond mixins often cited as problematic/confusing while keeping boilerplate code in each branch implementing "aggregated interface" at bay...
>
>my 0.0022€
>thomas

I do agree with composition over inheritance. As I say, that gives us godlike power. Imagine being able to compose an Olympic sprinter with a bigger heart and lungs at the starting line. Yet these inherit from some superclass.