Re: creaping coupling......
From: kirkk (kirk_at_kirkk.com)
Date: 02/24/05
- Next message: Jeff Brooks: "Re: Disadvantages of Inheritance, Polymorphism and Encapsulation"
- Previous message: H. S. Lahman: "Re: Responsibility-driven design"
- In reply to: Mark Nicholls: "Re: creaping coupling......"
- Next in thread: Mark Nicholls: "Re: creaping coupling......"
- Reply: Mark Nicholls: "Re: creaping coupling......"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 24 Feb 2005 14:38:32 -0800
I see little wrong with the initial design, aside from the fact that C
is coupled to B. Make C coupled to IB, which also indirectly couples it
to IA. But C is decoupled from all the B's and A's in the world. It can
be compiled separate from them, tested separate from them, and used
only with those you desire.
And if you place IB and IA in the same package or physical unit as C,
but separate the implementations, you'll gain even more flexibility.
Put your interfaces close to the classes that use them. Separate your
interfaces from the classes that implement them.
Kirk Knoernschild
www.kirkk.com
www.extensiblejava.com
Mark Nicholls wrote:
> "Mark Nicholls" <nicholls.mark@mtvne.com> wrote in message
> news:385oe0F5f9jj8U1@individual.net...
> > Is it me, I am being stupid, I keep coming across this
problem......
> >
> >
> >
> >
> > interface IB has a parameter of type IA.
> >
> > class B implements IB
> >
> > and class C instantiates an B....
> >
> > so (in .net though I expect this happens in a lot of strongly typed
> > languages).
> >
> > C has to know about how to instantiate a B.....fair enough.
> > C has to know that about IB.......damn.....why?
>
> ok, well, actually if C ever wants to do anything with B (assuming
the class
> interface B is empty), then C would need to know about IB.....but C
would
> not need to know the details of IB, just that B implements IB.
>
> > C has to know about IA then......disaster......why?
> > etc etc etc
> >
> > Soon C has to reference all sorts of stuff it not interested in.
> >
> > it seems to me that all C should need to know is that some method
> > (constuctor) returns something labelled B.....what you can actually
do
> with
> > B is incidental.
> >
> > Is there a way around this? (OK I could return 'object's and cast
in the
> > code that accesses the interfaces....but uuuuggghhhh)
> >
> >
>
> so let me mildly rephrase.....
>
> C has to know about how to instantiate a B.....fair enough.
> C has to know that about the existence of IB and that B implements
> it.....fair enough.
> C has to know the details of the methods of IB......!....no.....but
my
> compiler seems to reckon it does.
> C thus has to know the interfaces of all parameters in the methods of
> IB....!!......no.....but my compiler seems to reckon it does.
> recursively....!!!!......C has to know the complete tree of
interfaces
> stemming from B.....!!!......disaster.
- Next message: Jeff Brooks: "Re: Disadvantages of Inheritance, Polymorphism and Encapsulation"
- Previous message: H. S. Lahman: "Re: Responsibility-driven design"
- In reply to: Mark Nicholls: "Re: creaping coupling......"
- Next in thread: Mark Nicholls: "Re: creaping coupling......"
- Reply: Mark Nicholls: "Re: creaping coupling......"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|