>>>Sorry to burst your bubble, but the definition there still makes more sense than your kettles example. And I still think the expression is somehow wrong, but taken as a measure it's sort of okay. Is it a replacement for encapsulation or a way to measure it? Hmmmm....
>>
>>No. The kettle example is very apt. It is an assembly of sub assemblies which OOP is trying to emulate.
>
>But how is an "assembly of sub assemblies" fitting into cohesion? Is a code unit becoming more or less cohesive if over time delegates more of its tasks to sub-units, because it was discovered that these sub-units may come handy elsewhere?

Each subassembly is supposed to be cohesive. It is to be loosely coupled to other subassemblies to make up a cohesive new outer assemble. The code unit that delegates to subassemblies is still cohesive. A car engine with ignition and fuel delivery subsystems is still a cohesive whole. The code is the blueprint, so I do not and should not have 6 copies of any sub-assembly and I know I had this discussion with one of our peanut gallery. He felt is was necessary to copy the code into different libraries to ensure "cohesion". That was when I gave up on him. His other positions only make me glad I blocked him.

>
>>>The storage is completely irrelevant. The famous OOP question "where does the code go?" is not about files, it's about logic, "which object's job is this?".
>>
>>Yet I know many FoxPro people who insist that storage of the code is important.
>
>It is important for app management, where we come to entanglement - how granular do you want your code to be? I've seen a VFP exe grow from 56 K zo 3M just because one routine from a common library was added - because that library mentions something with visual controls in some unrelated class in the same vcx, which then drags in about half the framework into the pjx. In that sense, it is important. But logically it shouldn't be - I'd say we're rather talking about classes doing job of others, i.e. having methods unrelated to their reason to exist (like, say, a logger having its own set of pathing routines just to know how and where to create its file). Or, worse, some other piece of code calling a logger without ever logging anything, just because the logger has a few nice pathing methods. Avoiding such nonsense is, I agree, much more important than storage - which is basically just packaging. You can repackage the classes etc differently and the app would still have the same code inside.