Re: What do People do to avoid Tight Coupling?
From: Jay B. Harlow [MVP - Outlook] (Jay_Harlow_MVP_at_msn.com)
Date: 06/03/04
- Next message: SamSpade: "Use of Modules"
- Previous message: Saurabh: "Re: Controlbox MDI form"
- In reply to: Charles Law: "Re: What do People do to avoid Tight Coupling?"
- Next in thread: Charles Law: "Re: What do People do to avoid Tight Coupling?"
- Reply: Charles Law: "Re: What do People do to avoid Tight Coupling?"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 3 Jun 2004 07:42:35 -0500
Charles,
> I don't have the Fowler book, but I can feel a purchase or two coming on.
I
> have the GoF Design Patterns book, which does not mention the Separated
> Interface Pattern as such; perhaps under a different name (?).
Fowler's book takes off where the GoF book stops.
> I have used interfaces in much the way you describe, so I am reassured in
> that respect.
I may have miss read one of your other posts, I got the impression you did
not understand interfaces...
> With regard to the use of a proxy, it does save copying the data, but with
> around 50 events being bubbled, each with their own EventArgs class, that
> still means another 50 proxy classes.
It really comes down to: How much coupling are you willing to live with! ;-)
The proxy allows you to avoid coupling, have fair performance, and expose
all or most of the same properties in both events. At the expense of
creating the proxy classes...
> Just to clarify, you say 'assembly', I say 'project'. Are we talking about
> the same thing?
Yes
Hope this helps
Jay
"Charles Law" <blank@nowhere.com> wrote in message
news:uCm$ufVSEHA.2780@TK2MSFTNGP09.phx.gbl...
> Hi Jay
>
> I don't have the Fowler book, but I can feel a purchase or two coming on.
I
> have the GoF Design Patterns book, which does not mention the Separated
> Interface Pattern as such; perhaps under a different name (?).
>
> I have used interfaces in much the way you describe, so I am reassured in
> that respect.
>
> With regard to the use of a proxy, it does save copying the data, but with
> around 50 events being bubbled, each with their own EventArgs class, that
> still means another 50 proxy classes.
>
> Just to clarify, you say 'assembly', I say 'project'. Are we talking about
> the same thing?
>
> Charles
>
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in message
> news:u1EuDoQSEHA.620@TK2MSFTNGP10.phx.gbl...
> > Charles,
> > It sounds like you really need to learn the Separated Interface Pattern
> > (Martin Fowler's book).
> >
> > http://www.martinfowler.com/eaaCatalog/separatedInterface.html
> >
> > Define an Interface that Class1 uses that Class2 implements. Put this
> > interface in the same assembly as Class1 (or a third assembly). The
Class1
> > assembly needs to reference the assembly where the interface is defined
if
> > its not in the same assembly. The Class2 assembly needs to reference the
> > Class1 assembly & the assembly where the interface is defined. Class2
can
> > reference Class1 directly, while Class1 can only reference Class2 via
the
> > interface that it implements.
> >
> > Something like:
> > ' Assembly 1
> > Public Interface IClass2
> > Public Property Value1() As Integer
> > Public Sub Method1()
> > End Interface
> >
> > Public Class Class1
> >
> > Public Sub Test(ByVal object2 As IClass2)
> > If object2.Value1 = 100 Then
> > object2.Method1()
> > End If
> > End Sub
> >
> > End Class
> >
> > ' Assembly 2
> > ' References Assembly 1
> >
> > Public Class Class2
> > Implements IClass2
> >
> > Public Property Value1() As Integer Implements IClass2.Value1
> > ...
> >
> > Public Sub Method1() Implements IClass2.Value1
> > ...
> >
> > End Class
> >
> > Note instead of an Interface, you could use an Abstract Base Class
> > (MustInherit).
> >
> > The Interface IClass2 can contain events in addition to Properties,
> > Functions & Subs.
> >
> > Also to elimate the coupling between Presentation & Data, I would use a
> > Proxy object for the EventArgs instead of actually copying the data.
> >
> > Something like:
> >
> > ' From Data layer
> > Public Class DataEventArgs
> > Inherits EventArgs
> >
> > Private Readonly m_amount As Integer
> >
> > Public Sub New(amount As Integer)
> > m_amount = amount
> > End Sub
> >
> > Public Readonly Property Amount As Integer
> > Get
> > Return m_amount
> > End Get
> > End Property
> >
> > End Class
> >
> > ' From Domain Layer
> >
> > Public Class DomainEventArgs
> > Inherits EventArgs
> >
> > Private Readonly m_dataEventArgs As DataEventArgs
> >
> > Public Sub New(dataEventArgs As DataEventArgs)
> > m_dataEventArgs = dataEventArgs
> > End Sub
> >
> > Public Readonly Property Amount As Integer
> > Get
> > Return m_DataEventArgs.Amount
> > End Get
> > End Property
> >
> > End Class
> >
> > Although the Domain layer duplicates all the properties, the data itself
> is
> > not duplicate or exposed, as the DomainEventArgs acts as a Proxy for the
> > DataEventArgs, delegating all the calls to the DataEventArgs...
> >
> > Hope this helps
> > Jay
> >
> > "Charles Law" <blank@nowhere.com> wrote in message
> > news:uDWqYJMSEHA.2704@TK2MSFTNGP10.phx.gbl...
> > > Hi Jay
> > >
> > > > I suspect most of the time the info that the domain layer needs in
its
> > > > events is going to be different then the info needed in the data
> layer's
> > > > events, so each would have its own event handlers...
> > >
> > > I agree that this the case most of the time, it's just that in my case
> it
> > > isn't. If I used different EventArgs classes I would just be changing
> the
> > > object for the sake of it. No information is added or omitted as the
> event
> > > passes up the layers.
> > >
> > > As I described in my response to Dan, I have a set of custom controls
> that
> > > raise and sink events. These are instantiated by the presentation
layer,
> > but
> > > the command layer is where the corresponding events are sunk (sinked?)
> and
> > > raised. I have ended up with tighter coupling than the compiler/IDE is
> > > comfortable with, and I get random, erroneous build errors all the
time.
> I
> > > have seen others post about this problem, and it comes and goes for
me.
> At
> > > the moment it has come, and I can't build my solution because I get
> large
> > > numbers of spurious messages about handlers and events having
different
> > > signatures, when they haven't. That's why I am trying to loosen the
> > coupling
> > > so that I can just build the thing.
> > >
> > > Charles
> > >
> > >
> > > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP@msn.com> wrote in
> message
> > > news:eVqENGLSEHA.3140@tk2msftngp13.phx.gbl...
> > > > Charles,
> > > > > The presentation layer is coupled to the business layer, and the
> > > business
> > > > > layer is coupled to the data layer. So far so good.
> > > > Actually I normally couple the presentation layer to the domain
layer
> > > > (business layer) and couple the data layer to the domain layer!
> > > >
> > > > See Martin Fowler's book "Patterns of Enterprise Application
> > Architecture"
> > > > from Addison Wesley
> > > > http://www.martinfowler.com/books.html#eaa. The sections on Domain
> > Model,
> > > > Data Mapper, and Separated Interface discuss how to have the data
> layer
> > > > reference the domain layer, instead of having the domain layer
> reference
> > > the
> > > > data layer. Having the data layer reference the domain layer, allows
> > > > replacing the data layer very easily! Also I find it provides better
> > > > separation (less coupling)...
> > > >
> > > > > Suppose the data layer raises an event, and it passes Me (the
> sender)
> > as
> > > > an
> > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the
layer
> > > above
> > > > In one of my projects that data layer has custom event handlers
> > > > (MyEventArgs, a descendent of EventArgs), while the domain layer
> simply
> > > uses
> > > > EventHandler & passes EventArgs.Empty. As I found that the domain
> layer
> > > > needed to convey less information to the domain layer, then the data
> > layer
> > > > did to the domain layer.
> > > >
> > > > > We could define a business layer version of MyEventArgs - which is
> > > > actually
> > > > > identical to the one in the data layer - and copy each element to
> the
> > > new
> > > > > object before passing it on, but that is a lot of typing, and now
we
> > > have
> > > > > duplication.
> > > > I suspect most of the time the info that the domain layer needs in
its
> > > > events is going to be different then the info needed in the data
> layer's
> > > > events, so each would have its own event handlers...
> > > >
> > > > Hope this helps
> > > > Jay
> > > >
> > > >
> > > >
> > > >
> > > > "Charles Law" <blank@nowhere.com> wrote in message
> > > > news:eB2zheKSEHA.3140@tk2msftngp13.phx.gbl...
> > > > > Take a solution with a project hierarchy along the lines of an
> n-tier
> > > > > system, so that we have a data layer, business layer and
> presentation
> > > > layer.
> > > > > The presentation layer is coupled to the business layer, and the
> > > business
> > > > > layer is coupled to the data layer. So far so good.
> > > > >
> > > > > Suppose the data layer raises an event, and it passes Me (the
> sender)
> > as
> > > > an
> > > > > object, and e (MyEventArgs, a descendent of EventArgs) to the
layer
> > > above
> > > > > (the business layer). Suppose also that the business layer needs
to
> > pass
> > > > > this event on to the presentation layer. It sends Me as an object,
> but
> > > > what
> > > > > does it send e as? It can't send it as MyEventArgs because the
> > > > presentation
> > > > > layer knows nothing of such things. We could couple the
presentation
> > > layer
> > > > > to the data layer, so that it knows what a MyEventArgs is, but
> surely
> > > that
> > > > > is a no-no.
> > > > >
> > > > > We could also remove the definition of MyEventArgs to another
> project
> > to
> > > > > which everything is coupled, but now this common project is in
> danger
> > of
> > > > > being an eclectic mix of stuff that is really specific to
individual
> > > > > projects.
> > > > >
> > > > > We could define a business layer version of MyEventArgs - which is
> > > > actually
> > > > > identical to the one in the data layer - and copy each element to
> the
> > > new
> > > > > object before passing it on, but that is a lot of typing, and now
we
> > > have
> > > > > duplication.
> > > > >
> > > > > I am interested to hear what other people do in this situation.
> > > > >
> > > > > Charles
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
- Next message: SamSpade: "Use of Modules"
- Previous message: Saurabh: "Re: Controlbox MDI form"
- In reply to: Charles Law: "Re: What do People do to avoid Tight Coupling?"
- Next in thread: Charles Law: "Re: What do People do to avoid Tight Coupling?"
- Reply: Charles Law: "Re: What do People do to avoid Tight Coupling?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
