Subj : Re: What the bleep is Coupling? (was: Polymorphism sucks)
To   : comp.programming,comp.object
From : Chris Sonnack
Date : Thu Jul 28 2005 08:28 pm

Robert Maas writes:

>> C'n'P is a terrible form of coding IF ITS PURPOSE IS THE DUPLICATION
>> OF LINKED CODE.  In other words, if you know you have to do the same
>> thing in two places, and you do it by duplicating code, that's a
>> mistake.  A big mistake.
> 
> [...]
> The question arises when you don't want to do exactly the same thing,
> [snip]

IOW, when the purpose isn't duplication.  Agreed.


>> Coupling is: I have a class "Foo" and a class "Bar" (separate units),
>> and Foo needs to know stuff about Bar.  Therefore, Foo is coupled to
>> Bar.  This can be disasterous if someone else controls Bar's design.
> 
> If Bar is free to change the public interface from day to day, then
> don't use Bar at all, it's a crock of shit.

The only time I can imagine an interface changing from "day to day" is
during a development cycle, and one may not have the option of not
using Bar.  It may be the requirement to use Bar.  In such a case, you
just have to try to keep up.

> If the public interface for Bar is stable, then it's perfectly fine
> for Foo to depend on knowledge of Bar's public interface.

Right.  The point is, they are coupled.  IF Bar changes at some point
in the future, Foo needs to change, too.


>> In most languages, if you have a function Snork(int x, int y), all
>> calls to Snork() are coupled in that they need to pass a pair of
>> appropriate ints in the right order.
> 
> But the public interface documentation should say clearly what the
> respective roles of first int and second int are,

Of course.  The point is (regard the Subject: matter) they are coupled.

>> (Some languages help decouple by providing the ability to pass
>> arguments by name.  Thus, you can at least avoid the ordering
>> coupling.)
> 
> You still need to RTFM to learn the names of the parameters and their
> semantics.

Right.  Coupling still exists.  If you read and undestood the earlier
part of this thread, you recognize that the question asked was in part
as expressed by the Subject: and also whether there was "good" coupling
and "bad" coupling and how could you tell the difference.


>> Functions coupling is *controlled* by publishing to the compiler
>> information about Snork().  That way, if a caller changes, or if
>> Snork() changes, the compiler screams.
> 
> IMO If you purchase a Snork module, and later somebody reverses the
> sequences of parameters out from under your application, that's an
> unpardonable offense, and you deserve double your money back.

This is more about Snork() being your own function that you called with
detectably wrong arguments or that you decided to re-write Snork() and
didn't find all the call points.  The compiler will help you out then.

(In a statically typed language, anyway.)


>> The reason coupling is "bad" is because it introduces dependancies
>> that must be managed.  The higher the management cost, the worse
>> the coupling.
> 
> Every time you call a function with more than one parameter, you have
> such "coupling".

Right.

> Most of the time the right thing to do is pass a single object that
> encapsulates all the various bindings needed.

Not sure I agree with that, since it increases coupling (both caller
and callee need to know the passed object).  It's also, IME, messier.
I prefer:

	Snork(42, "Green", INCLUDE_ALL);
To:
	var  football = new Football(42,"Green",INCLUDE_ALL);
	Snork(football);
Or:
	Snork(new Football(42,"Green",INCLUDE_ALL));
Or:
	var  football = new Football;
	football.arg1 = 42;
	football.arg2 = "Green";
	football.arg3 = INCLUDE_ALL;
	Snork(football);

	
>> cross-references can give you an index to certain forms of coupling.
>> You need to do more than just list them to determine if they are
>> under control, unavoidable or worth refactoring.
> 
> One thing you might do is simply draw a structure diagram, showing at
> the top your main program, under it anything it directly calls, all the
> way to low-level utilities at the bottom.

Don't try to explain that to "topmind".  He doesn't believe in trees or
hierarchical thingamabobs.  (-:


-- 
|_ CJSonnack <Chris@Sonnack.com> _____________| How's my programming? |
|_ http://www.Sonnack.com/ ___________________| Call: 1-800-DEV-NULL  |
|_____________________________________________|_______________________|

.