Subj : Re: What the bleep is Coupling? (was: Polymorphism sucks)
To   : comp.programming,comp.object
From : Chris Sonnack
Date : Fri Jul 08 2005 10:40 am

topmind writes:

>>>> As A and B are coupled, changes to A require changes to B.
>>>>
>>>> The more decoupled they are, the less changes ripple thru
>>>> the system.
>>>
>>> Okay, but how does polymorphism allegedly
>>> avoid this for ALL possible changes?
>>
>> No one I've heard has alleged this.
> 
> Well, I don't know what the heck you are alleging.

What several people have now stated repeatedly is...

* Coupling creates dependancies between separate parts of the system.
* Dependancies increase the difficulty of maintanence.
~~~
* Therefore, coupling is to be *avoided*, subject to other constraints.

What part of that is problematic for you?


> Even in the worse-case OO textbook "duplicate case/switch list"
> scenarios, a change to case list A does not necessarily "require"
> a change to case list B. List B may not care about the new option.


In general, the duplicate selects do require knowing about the new
type.  Consider your bank account example.  If the bank adds a new
account type, what are the odds that most--if not all--the rest of
the system needs to know about it?

The usual answer is: Very high.

> Now you may allege that it is most likely that changes to case
> list A will result in a change to case list B, but that is not
> "requires". That is a statement of probability.

Obviously.  IME (and obviously in the E of others), adding a new
"thing" to the system *usually* implies that the system needs to
know about it (otherwise, why bother adding it?).

> "Requires" is a 100% probability.

You're getting lost in word games.  If the rest of the system is
going to process the new "thing", it's "required" to know about
it.  There's no "probability" involved in the "requirement", it's
a consequence of the change.

Whether a change requires the system to know about the new "thing"
is a different matter--one related to design and the exact nature
of the change.  But, again, IME, the *probability* of adding a
new thing is that the system does need to know about it.

Polymorphism just provides a mechanism that *can* decouple how the
system treats "things".  Through p/m, the system can be designed
to deal with "generic things", and this allows you to add new things
IF their interface matches a generic thing.

> (BTW, there is some coupling and change pattern
> discussion also happening in the "OOP/OOD Design"
> topic.)

Don't see that thread here in comp.programming.

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

.