Re: caching object ?
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Sat, 13 Aug 2005 18:49:01 GMT
Responding to Gabriel...
Container(){
A a = new A(this); B b = new B(this); and so on }
Now, A,B,C are not necessaraly linked together. it is just that if C who is created by B ever needs an object, he doesn't have to ask B for A for instance, he just ask his parent for the Container which wil give him A.
Since all objects have a reference to the container, it's easier to "go ask container" than to think : well I need this object (X) thus either :
the class who instantied me has to know about X
or I could create a new X
or my solution : my parent knows the container and the container knows everyone (he created everyone at launch time).
But, since this didn't appear to be a classic pattern, I think the thing must not have been much used :) and thus should be dropped :)
To make it short, it just seemed a good idea which works well but implies more drawbacks than I have considered.
thank you very much again, learning comes by confronting ideas :)
What you seem to be describing here is mostly just a specialized collection class. For example, suppose we had (make sure your reader is set up to interpret fixed fonts):
R4 * *
+---------------- [B] ---------+
| * |
R1 * | 1 R5 * |
+---------------- [A] -------------- [C] -----+ |
| 1 * | * | |
| 1 R2 | | |
[Client] ------------ [E] ----------------+ | |
| 1 1 * 1 R6 | |
| | |
| * 1 | |
+---------------- [D] ------------------------+ |
R3 | 1 R7 |
| R8 |
+------------------------------+Now a given Client may access multiple As, Es, and Ds via the R1, R2, and R3 relationships, respectively. In turn, any given A can access multiple Bs and Cs via the R4 and R5 relationships; any E can access multiple Cs via the R6 relationship; and any given D can access multiple Cs and Bs by the R7 and R8 relationships. At the OOP level one would likely have a collection class for each 1:* relationship.
If a given Client needed to access, say, the Bs associated with a particular A, it would find the A in the R1 collection class and then it would access the R4 collection class for that particular A. Thus the collection classes are organizing the Bs and Cs for particular As, Ds, and Es.
In your case the relationships are not 1:* but 1:1 so you don't need to organize multiple instances for each relationship. What you are trying to do is make sure that one gets the matching C for the B for a given A. IOW, you are using the container to collect together the right B and C by combining the R4 and R5 relationships so that the Client has one navigation to get to both.
That really should not be necessary if the R4 and R5 relationships are instantiated individually. A given A will always get the right (matched) B and C so long as whoever instantiates the relationships did it correctly. IOW, the matching rules are implicit in instantiating the R4 and R5 pointers in A.
In addition, it is a more general approach. To see that suppose we have instances of [A]: {A1, A2}, of [B]: {B1, B2, B3}, of [C]: {C1, C2, C3}, and of [D]: {D1, D2, D3}. Now suppose the relationships are organized in the problem space so that we have:
instances of [A]
A1 is related to {B1, C3}
A2 is related to {B2, C1}instances of [D]
D1 is related to {B1, C3}
D2 is related to {B2, C2}
D3 is related to {B3, C1}Note that A1 and D1 could have the same container but A2, D2, and D3 need unique containers. Sharing or duplicating a container for A1 and D1 will likely lead to complications in ensuring referential integrity, not to mention managing the containers themselves. But if each A and D has its relationships instantiated _for the A or D in hand_, then one does not care about sharing instances at all; one just has to think about which Bs and Cs go with the A or D in hand.
Similarly, if the Client needs to access the B or C for a particular A or D, it always navigates to it in exactly the same way and does not need to understand the rules for logically connecting a particular B or C to a particular A or D.
************* There is nothing wrong with me that could not be cured by a capful of Drano.
H. S. Lahman hsl@xxxxxxxxxxxxxxxxx Pathfinder Solutions -- Put MDA to Work http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman (888)OOA-PATH
.
- References:
- caching object ?
- From: gabriel
- Re: caching object ?
- From: H. S. Lahman
- Re: caching object ?
- From: gabriel
- caching object ?
- Prev by Date: Re: defining quality of OOA and OOD models
- Next by Date: Re: OO design examples
- Previous by thread: Re: caching object ?
- Next by thread: Standard UML to Java binding ?
- Index(es):
Relevant Pages
|
