question about component integration or assembly
in [OOP]
|
Prev: china wholesale nike jordan sneakers WWW.21cn-shoes.COM discount gucci prada puma
Next: Dynamic foreach algorithm
From: shashank on 19 Jan 2008 04:07 On Jan 19, 12:42 pm, hanliong <liongs...(a)gmail.com> wrote: > On Jan 19, 10:19 am, "H. S. Lahman" <h...(a)pathfindermda.com> wrote: > > > 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. Yes. and this is application developer/ assembler responsibility to wire up appropriate components to realize application behavior. > Anyway, on second thought, you might be right. The wiring should be > done at component developer's site. As this specific wiring is > supposedly beyond client area. Or is it not? Application builder specifies components of the system, which then may get developed independently at various locations. Once developed, all the components are assembled and configured by application developer/ assembler who then makes proper configuration to individual components and wire them together to create assembly/ application blue print. This blue print (assembly descriptor file - an xml file) is given as input to assembly and deployment infrastructure that makes best effort to install, instantiate and configure individual components to realize application. regards, shashank > Please enlight me more. > > Regards, Han.
From: H. S. Lahman on 21 Jan 2008 18:28
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(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH |