Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Dependencies in Component Diagram

 
Sridhar Raman
Ranch Hand
Posts: 142
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
Can a component sit in the Component Diagram without any dependencies? For example, InterceptingFilter?

Thanks in advance
Sridhar
 
Thomas Taeger
Ranch Hand
Posts: 311
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Sridhar,
thank you for this question that helped me
getting it clearer myself.
First let us define Dependency:
Component B depends on component A if
a code change (also called a definition change,
but not just state/data change) in A
makes it necessary to recompile and redeploy B too.
Dependencies are to be avoided as far as possible
to keep our systems low coupled.

1. Calling via interfaces as much as possible
(without knowing their implementations)
is a way to ensure decoupling.
So if you you have introduced interfaces
to your component diagram then it might be
possible to avoid code dependencies widely.
You draw the dependency arrrow to
the interface of the supplying component
that offeres that interface and its
implementation. This means that any code
change in the implementation will not affect
the client code as long as the interface code
is not changed.

2. A second way to ensure decoupling is
passing names instead of writing an interface
offering methods. Examples are
Class.forName( "name").newInstance(),
or, for your example of the Intercepting
Filter it might be forwarding by name.
With this you can avoid any dependencies between
your filters in two strategies:
For example each filter of your FilterChain
(according to D.Alur et a., "Core J2EE Patterns", p.154)
is implemented as a servlet, and
each servlet forwards to the next servlet/filter
not hard coded but in a _declarative_ way, i.e.:
a) for using the Custom Filter Strategy:
. by taking the next action/URL
. from a Property file for example, or
b) for using the (better, looser coupling)
. Standard Filter Strategy:
. by defining the FilterChain declaratively
. in the deployment descriptor.
Then (for a and b) one filter-code needs not
know the next one, therefore you need no
[code-]dependency between them and no arraows
between those servlets at all.
Hope that helps,
tomte.
PS: thanks to Heiko L. who just has brought this light to me according to one of my own questions.
[ February 25, 2004: Message edited by: Thomas Taeger ]
[ February 25, 2004: Message edited by: Thomas Taeger ]
[ February 25, 2004: Message edited by: Thomas Taeger ]
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic