Vitaliy wrote:
>> Choose one, Bolivar cannot
>> carry double.
>
> No need to pick one. The two can (and should) be practiced in parallel, and
> making your code more cohesive can at the same time make it less coupled,
> and vice versa.

This was "Self documenting code vs. Comments" thread. The question was kind of:
When we break the "big" sub down into smaller ones with good
meaningfull names, and the smaller one is holding some unique
functionality that will never be reused in other subs; does this
increase understandability of the code and how it will affect "loose
coupling" and "tight cohesion" properties of the system.

Let's see,  yes, the code will be easier to understand, but what with
"loose coupling" and "tight cohesion"?
- "tight cohesion": yes, the unique functionality will be separated
out of the rest, making the rest more "cohesive";
- "loose coupling" - _NO_, there is no need to make the separated
functionality be "loosely coupled" to the parent sub, for it won't be
used anywhere else in the code, just separate it out.

That's why "Choose one (tight cohesion in that case), Bolivar cannot
carry double".


> An analogy is useful here. A modern car is comprised of millions of
> parts, and yet the engineers manage to have a way of making sense of this
> beast. At the top level, they work with systems (powertrain, chassis).
> Systems can themselves be broken down into subsystems, assemblies, and
> subassemblies.

Still it would be stupid to develop the universal engine that is
loosely coupled to whatever hardware it will be installed on
("shouldn't care who is using it"). The engines should be different to
bikes, trucks and jets, though withing the groups they may be "loosely
coupled' to vehicle or may not, it depends. The idea of breaking a
system down into subsystems is trivial. Non-trivial is doing that
practically wise.
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist