[860] in java-interest
Re:mutual dependencies among public classes
daemon@ATHENA.MIT.EDU (Bill Burcham)
Fri Aug 11 21:21:07 1995
Date: Fri, 11 Aug 95 10:07:15 MST
From: Bill Burcham <billb@ripley.sunquest.com>
To: econsoft@wintermute.co.uk (David Gunn)
Cc: java-interest@java.sun.com
In-Reply-To: <199508111223.NAA04059@oberon.wintermute.co.uk>
One way to break these cyclic references is to use java interfaces. I
have done a similar thing with Objective-C protocols.
If you have two classes (A and B) which need to "know" something about
one another, put _those_ _aspects_ of A and B's interfaces in a couple
of java interfaces (say B'sA and A'sB). Then A and B can "specialize"
those interfaces.
A quick-and-dirty application of this approach is to let A use B's
_class_ interface, and define a B'sA interface for B to use (this
allows you to have one less interface).
This can be taken to its logical conclusion wherein classes refer to
only interfaces (never other classes). This opens up all kinds of
very cool posibilities such as abstract factories. I posit that
referring to one class from another yields extremely brittle systems
and that using "interfaces everywhere" along with abstract factories
yields very cool systems.
I would argue that the above approach is _always_ the right thing to
do and that the java standard should continue to enforce its current
functionality in this regard.
--
Bill Burcham billb@sunquest.sunquest.com "A little more you think,
520.733.6361 Office 4801 East Broadway a little less you code"
520.733.6602 FAX Tucson, AZ 85711 3610
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
