Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Coupling of objects

Reply
Thread Tools

Coupling of objects

 
 
dover
Guest
Posts: n/a
 
      07-11-2004
It has be often mentioned that the coupling among objects should be avoided.

What're the major cases that objects are closed coupled?

How to avoid such cases?

Many thanks!


 
Reply With Quote
 
 
 
 
Phlip
Guest
Posts: n/a
 
      07-11-2004
dover wrote:

> It has be often mentioned that the coupling among objects should be

avoided.

Define coupling. All authors seem to "know it when they see it".

> What're the major cases that objects are closed coupled?


I (authoritatively) define coupling as "A must change only because B
changed."

Put another way, I associate my definition with a transition. Staring at a
static instance of A and B won't tell if a given change, C, will reveal
coupling. Attempting the change will reveal it.

The other kind of association is "coherency". That essentially means "good
coupling". I define it as "A and B share legitimate reasons to change."

> How to avoid such cases?


Write lots of unit tests. Write them before writing the tested code, and
make them fail before making the tested code pass. Then refactor, testing
every few edits, until your design contains no duplicated definitions of
behavior.

Those forces overwhelmingly crush out all possible coupling from your
design. Under such a system you honestly needn't fret about coupling; it
becomes a non-issue, like bugs.

For example:

int main()
{

Source aSource("a b\nc, d");

string
token = aSource.pullNextToken(); assert("a" == token);
token = aSource.pullNextToken(); assert("b" == token);
token = aSource.pullNextToken(); assert("c" == token);
token = aSource.pullNextToken(); assert("d" == token);
token = aSource.pullNextToken(); assert("" == token);
// EOT!
}

That's just one puny test, lacking a test rig such as CppUnit. But it
already proves a very important aspect of the class Source's coupling.

You can construct a Source object using only main() and a string argument.
You are not required to construct or deploy or call or instantiate or
register or jump-thru-hoops any other objects, just to get a useful Source
going.

The complete application that code grew into appears here:

http://www.c2.com/cgi/wiki?MsWindowsResourceLint

I would be interested to learn if anyone thought any of my classes in there
were coupled. Or incoherent.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces


 
Reply With Quote
 
 
 
 
David Rubin
Guest
Posts: n/a
 
      07-11-2004
"dover" <(E-Mail Removed)> wrote in message news:<P42Ic.81237$(E-Mail Removed)>...
> It has be often mentioned that the coupling among objects should be avoided.
>
> What're the major cases that objects are closed coupled?


1. inheritance
e.g., class A : public class B {};

2. friendship
e.g., class B; class A { friend class B; };

3. substantive use of class B in the interface of class A
e.g. A::foo(B b);

4. substantive use of class B in the implementation of class A
e.g., A::foo() { B b; }

> How to avoid such cases?


See Lakos.

> Many thanks!


/david
 
Reply With Quote
 
David Rubin
Guest
Posts: n/a
 
      07-11-2004
"Phlip" <(E-Mail Removed)> wrote in message news:<iO3Ic.3195$(E-Mail Removed) om>...

[snip]
> I (authoritatively) define coupling as "A must change only because B
> changed."


s/change/re-compile/

[snip]
> > How to avoid such cases?

>
> Write lots of unit tests. Write them before writing the tested code, and
> make them fail before making the tested code pass. Then refactor, testing
> every few edits, until your design contains no duplicated definitions of
> behavior.


To me, this approach encourages you to design to the unit test suite
rather than to the problem domain. I have never had a good experience
writing tests before I write the interface, but I guess it's good to
experiment.

> Those forces overwhelmingly crush out all possible coupling from your
> design. Under such a system you honestly needn't fret about coupling; it
> becomes a non-issue, like bugs.
>
> For example:
>
> int main()
> {
> Source aSource("a b\nc, d");
> string token;
> token = aSource.pullNextToken();
> assert("a" == token);


FWIW, I find it useful to define and use ASSERT (or redefine assert())
so that it doesn't stop the program execution at each failed
assertion. Otherwise, you may have to run the test driver several
times to solve one class of error.

/david
 
Reply With Quote
 
Phlip
Guest
Posts: n/a
 
      07-11-2004
David Rubin wrote:

> Phlip wrote:
>
> [snip]
> > I (authoritatively) define coupling as "A must change only because B
> > changed."

>
> s/change/re-compile/


That is an artifact of how C++'s compilation model weds most kinds of
coupling to the recompile system. Put another way, you can build very large
systems in C++ without excess recompiles if you take care to follow good OO
design principles such as "program to the interface, not to the
implementation".

But you can still couple A and B unfairly, but A _doesn't_ recompile when B
changes. It just breaks.

> [snip]
> > > How to avoid such cases?

> >
> > Write lots of unit tests. Write them before writing the tested code, and
> > make them fail before making the tested code pass. Then refactor,

testing
> > every few edits, until your design contains no duplicated definitions of
> > behavior.

>
> To me, this approach encourages you to design to the unit test suite
> rather than to the problem domain. I have never had a good experience
> writing tests before I write the interface, but I guess it's good to
> experiment.


One designs them both, together, in tiny increments. One doesn't write many
test cases up front.

> > Those forces overwhelmingly crush out all possible coupling from your
> > design. Under such a system you honestly needn't fret about coupling; it
> > becomes a non-issue, like bugs.
> >
> > For example:
> >
> > int main()
> > {
> > Source aSource("a b\nc, d");
> > string token;
> > token = aSource.pullNextToken();
> > assert("a" == token);

>
> FWIW, I find it useful to define and use ASSERT (or redefine assert())
> so that it doesn't stop the program execution at each failed
> assertion.


Yes! ASSERT() should invoke a breakpoint expanded in the calling function,
not deep in the C++ Standard Library.

> Otherwise, you may have to run the test driver several
> times to solve one class of error.


No! If you run the tests every 1~10 edits, and predict the results of each
run, then any unexpected failure is cause to simply Undo the most recent
edits.

--
Phlip
http://industrialxp.org/community/bi...UserInterfaces



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Inquiry: Differences between coupling vs cohesion and encapsulation vs. polymorphism samtse@gmail.com Java 1 03-01-2005 05:16 AM
Coupling Text & Images? xmp333@yahoo.com HTML 3 01-18-2005 10:05 PM
Coupling Contacts - Nikon 7500 Donald Gray Digital Photography 3 06-04-2004 04:25 PM
DVD Verdict reviews: DOWN PERISCOPE, COUPLING: THE COMPLETE SECOND SEASON, and more! DVD Verdict DVD Video 0 04-01-2004 10:03 AM
Coupling Tomcat 5.0 with Apache 2.0.48 Linda van der Pal Java 0 02-13-2004 10:16 AM



Advertisments