>>>>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)
>
>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.

>
>>A thing must be internally cohesive.
>
>Sure. Because externally cohesive is called adhesive, aka sticky.
>
>>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.
>
>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.