Re: question about component integration or assembly
- From: "H. S. Lahman" <hsl@xxxxxxxxxxxxxxxxx>
- Date: Mon, 21 Jan 2008 23:28:17 GMT
Responding to Hanliong...
So what has all this got to do with your comments? The main point is
that Who gets "wired up" is driven by unique rules and policies that are
probably encapsulated somewhere other than in the client of A or B. If A
and B are "wired" together, then that is none of the client's business.
Yes, this is my understanding previously. Wiring a component A to B is
not the problem of a client application. However as mentioned by
Shashank if we bought a PowerGenerator component and a VendingMachine
component, and our client application is about a software application
that calculates the selling of items from a Vending machine. Then
this client application should wire PowerGenerator to
VendingMachine.
What we have is:
[Client]
| *
|
| R1
|
| talks to
| 1
[VendingMachine]
| *
|
| R2
|
| gets power from
| 1
[PowerGenerator]
The R2 relationship is highly unlikely to be any of the Client's business. That is, the R2 relationship will usually be instantiated by someone else other than Client and VendingMachine's navigation of that relationship is a private matter between VendingMachine and PowerGenerator.
There are two contexts for defining R2. One is that the [VendingMachine] implementation depends upon a specific PowerGenerator being available. That is, the design of the [VendingMachine] component requires that a specific PowerGenerator be available. In that case the provider of the [VendingMachine] component needs to also provide the PowerGenerator component (e.g., in the same DLL).
The second context arises when the application needs to glue together components. Then the application must explicitly provide instantiation of both the R1 and R2 relations. Client may or may not provide that instantiation. The corollary is that the collaboration between a VendingMachine and a PowerGenerator needs to be reasonably generic. That is, the application can provide /any/ component for [PowerGenerator] so long as it provides an acceptable interface and has an acceptable semantics _in the problem context_.
The second context is common when components are used because a basic tenet of component engineering is that one can cobble together big components from small components and that often requires that the small components must talk to one another. Well engineered components will provide interfaces that will make it <relatively> easy to glue them together.
The first case above would come into play if [VendingMachine] was a big component that was cobbled together from [PowerGenerator] and other samll components. It would then be the responsibility of the big component designer to provide all the necessary glue and the only relationship the application would have to worry about would be the one that [Client] sees, R1.
The second case would come into play when both [VendingMachine] and [PowerGenerator] were peer components. The application would then be responsible for making them play together properly, which would mean instantiating R2. IOW, it is serendipity that R2 is between two components; at that point they (and possibly [Client]) are all just objects collaborating to solve the [problem in hand. The key point, though, is that the application will be more robust if [Client] does not know about R2 when it collaborates with [VendingMachine].
--
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- References:
- question about component integration or assembly
- From: liongster
- Re: question about component integration or assembly
- From: H. S. Lahman
- Re: question about component integration or assembly
- From: liongster
- Re: question about component integration or assembly
- From: Matteo Bordin
- Re: question about component integration or assembly
- From: H. S. Lahman
- Re: question about component integration or assembly
- From: hanliong
- question about component integration or assembly
- Prev by Date: Re: Business objects, subset of collection
- Next by Date: Re: Dynamic foreach algorithm
- Previous by thread: Re: question about component integration or assembly
- Next by thread: Re: question about component integration or assembly
- Index(es):
Relevant Pages
|