Re: Definitions
From: rackri (rackri_at_yahoo.it)
Date: 10/22/03
- Previous message: Michael C. Ferguson: "Re: Definitions"
- In reply to: Universe: "Re: Definitions"
- Next in thread: Universe: "Re: Definitions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 22 Oct 2003 00:17:49 -0700
Thanks a lot, Elliott.
In many articles (e.g. those explaining the inheritance vs composition
tradeoff) I found those concepts which were very difficult to
grasp for a newbie like me. Thanks!
-- Roberto
"Universe" <universe@covad.net> wrote in message news:<9802$3f956719$3f47e403$23433@msgid.meganewsservers.com>...
> "rackri" <rackri@yahoo.it> wrote in message
> news:7a2f224b.0310190050.39f26b50@posting.google.com...
> > Hi all,
> >
> > can you please help me to understand these concepts:
> >
> > - delegation
>
> Class A requests Class B to perform an operation that is integral to the
> key use case responsibility of Class A.
>
> The request from Class A to Class B is not just any operation but an
> operation that is essential to 'is-a' nature/character of Class A.
>
> The reason the operation is essential to Class A is because delegation
> in OO is identified with being a mechanism used *in lieu* of
> *inheritance*.
>
> Studies show that in general inheritance is more efficient regarding
> space and time. However there are other pro and con contexts where many
> find that delegation is preferable to inheritance.
>
> Finally, delegation implies a "part/whole" relationship between Class A
> and Class B, where Class B is perceived to be a "part" of the whole
> essential role responsibility of Class A. The particular form of
> "part/whole" relationship between the 2 classes may vary.
>
> The relationship may be - "aggregate", "composition", "uses", simple
> "association", or other. Context and design tradeoffs determine which
> kind of "part/whole" relationship between Class A and Class B is optimal
> in any given circumstance, or set of circumstances.
>
> [This is 1 reason it would be a travesty, or is a travesty, for UML
> authors to "give up" on defining, including, and distinguishing amongst
> "aggregation", "composition", and "uses" as significant notational
> elements of UML.]
>
> > - forwarding
>
> Forwarding is the passing along of data or activation signal(s) from one
> class to another.
>
> Forwarding is what Class A does when "sending", "invoking", "dispatching
> to" Class B. However Forwarding is not limited to Delegation.
> Forwarding may occur with Delegation or some other relationship between
> the sending and receiving classes.
>
> > - indirection
>
> "Indirection" is when Class A invokes, dispatches to a method on Class B
> by using the address of the method rather than directly by the name of
> the method. "Indirection" is also what happens when Class A sends data
> to Class B using the address of the data as opposed to directly
> referring to the value of the data.
>
> In all of this Class A is operating by calling methods or passing data
> by "reference" versus directly "by value". C/C++?Pascal/VB pointers are
> frequently used and notable a mechanisms used by one code module to make
> a method call, or send data "by reference", that is by "Indirection".
>
> > - redirection
>
> "Redirection" is possible with "Indirection". Class A may think it is
> sending data to Class B or calling a method on Class B, but Class C, or
> other process inserts the address of some other module. So that the
> call or send by Class A has been "Redirected", via "Indirection".
>
> Elliott
> --
> *~* Theory Leads, Practice Verifies *~*
> *~* Global Plans + IID (Iterative & Incremental Development) *~*
- Previous message: Michael C. Ferguson: "Re: Definitions"
- In reply to: Universe: "Re: Definitions"
- Next in thread: Universe: "Re: Definitions"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
