Re: Managing multiple instances

Responding to Stocks...

Yes, falling apart would not surprise me. This is a real architectural
problem because the structure is being hard-wired into object
implementations. The proper OOA/D way to handle this is through
peer-to-peer relationships.


So even if the relationship is a "has-a" it should be implemented in
terms of collection rather than hard coding in a reference attribute?

Yes. In UML there is a notion of a 'composition association', which is typically implemented at the 3GL level with embedded objects. However, that notion is rather special because it carries two semantics: a notion of Whole/Part semantics must exist explicitly in the problem space and the constraint that the Whole controls the disposition of the Part (i.e., the Part's life cycle is tied to the Whole's life cycle for referential integrity purposes). And not all MDA profiles for UML even use that notion. IOW, has-a is a kind of luke warm composition.

[Note, BTW, that several of the newer OOPLs do not even support embedded objects (other than fundamental types). That is, the syntax only supports defining references to objects. One reason is that such embedding tends to be more difficult to maintain.]

All you then need is some way for the clients to know how to ask for a
specific instance of [C] and/or [A]. But you already have that problem
because the client needs to use the right hard-wired numbers. That
implies some context the client understands that can be mapped into
whatever new identity scheme you employ.


That is the crux of my whole problem, managing an identity when objects
being identified are attributes of other classes. There is more than
one instance of a class created in different context and keeping the
identity unique enough for client code to correctly request the
appropriate object from the data structure. I need something unqiue
that will not change if the rest of the system changes.

As someone suggested you can use "smart" pointers for identity. You can also go the RDB route and embed an identity attribute in the object when it is created. In the end, though, the client needs to know what the identity is for the object it wants. That will probably mean that you have to have some sort of lookup table somewhere in the implementation. You will also need some way (e.g., a code) to describe the client context so that it can be mapped to the actual object identity (e.g., an index into the lookup table that yields a reference).

For example, suppose the target objects ([A]) represent different models of an automobile. The hard-wired code embeds a number that maps to a model in the context where each model is accessed. That number is essentially a code for the model number and one could use it in a lookup table to get a reference to the model object.

In my previous message I said that changing the changing the identity scheme was <probably> largely mechanical. All you have to provide is an enumeration variable that is named for the models (among other alternatives for decoupling). That enumeration yields a code number that is defined in one place (where the enumeration is initialized). But it can be used in a table lookup from any context to get a reference. That is the mechanical part of decoupling identity.

The interesting part from an architectural viewpoint lies in who owns the lookup table. That lookup table logically gets initialized as the model objects are created. One common way to implement that is via constructors who are passed the enumeration code. They put the reference in the proper place in a static class table for the enumeration code. Then one can provide a static Find class method that does the table lookup given the model code. In effect the collection is the lookup table in the Model class.

The disadvantage is that the Find searches the entire collection of Model instances. But you may have a further constraint that only certain models are available relative to a particular C. Then the collection class for the R2 relationship should own the lookup table because it may only collect certain models. (It's lookup table would likely have a NULL entry for models that had not been assigned to the particular C's R2 relationship so that an invalid request could be detected.)

In this case, the original mapping of model enumeration mnemonic to reference is still owned by the Model class so that it remains in one place. But whoever instantiates the R2 relationship needs to invoke Add (model mnemonic, reference). They use the same mnemonic to get the reference from the static Model::Find.

Thus, in any case, given the enumeration variable for models one can do all of the collection management, model creation, and collaboration addressing in terms of only the model code mnemonic. The rules and policies for mapping of the context mnemonic to references are still encapsulated in one place (the Model class' constructors).

As it happens, an OOA/D model might look this way even for your existing
structure. The difference lies in the way the collections are
hard-wired now within objects vs. the separation of concerns for the
rules and policies of access, which should be in some other "factory"
object that manages instantiation of [A], [B], and [C] instances and
their relationships. The difference would also be reflected in the way
one navigates the relationships for collaboration.


So if I read this they way you intended, you are recommending a factory
or builder to do the initial creation of all objects rather than
allowing objects that contain other objects do the creation?

Yes, very much so. Unless instantiation is trivial and unlikely to become more complicated, it is generally good practice to encapsulate the rules and policies for instantiation away from the rules and policies of collaboration. Those sets of rules and policies are likely to be different and largely independent. To put it simplistically: instantiation is about Who participates in collaborations while the collaborations themselves are more about When and How. (It is no accident that almost a third of the GoF patterns are for "factory" situations.)


*************
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



.

Relevant Pages

  • Re: C++ design question
    ... >>and policies for object and relationship instantiation (object ... way to do that in OOA/D is via separation of concerns and encapsulation. ... >>conditional one can't implement it with a reference. ... >>policies ensures that the developer thinks about them. ...
    (comp.object)
  • Re: Singletons
    ... There are four basic ways to implement a relationship: embedding an object in the implementation of another object; employing a referential pointer; passing an object reference as a message argument; and using an RDB-style search of instances by explicit identifier. ... Relationships are always implemented and navigated when addressing collaboration messages. ... By modifying the context I meant that one defines the solution flow of control differently so that the instantiation can be done in one place rather than in several. ...
    (comp.object)
  • Re: Abstract public member variales?
    ... Since the direction of these relationships is now clear, if I am correct then it must be that every Deconstructor object has references to ObjectA, ObjectB, and ObjectC, then the various concrete deconstructors choose the appropriate reference to save so that ConcreteA saves ObjectA and ConcreteB saves ObjectB, etc. ... that instantiation is a separate responsibility than the one triggering the actual collaboration activity of saving the object. ... I think that saying this technique uses the Strategy pattern is misleading. ...
    (comp.object)
  • RE: Object instantiation in C#
    ... MyObject obj; ... > - If I use 'new' to instantiate an object, but the reference variable I use ... "Dave" wrote: ... > instantiation mechanism, and would be grateful if someone could clarify the ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: How to match a text value to a number value?
    ... The ONLY solution I've found for this is to suffix an alpha character ... to all values in the lookup list and reference list. ... Excel sees it all as text. ...
    (microsoft.public.excel.programming)