Re: Managing multiple instances

Responding to Stocks...

When other parts of the application need to access a particular
instance of a specific object they request the object by a type
enumeration and provide the instance number of that object that is
requested. Multiple instances of the same object may be kept in the
data structure. I did not design this and don't believe in "all the
core application classes should inherit from X and they all should be
stored in the SAME data structure" but I have to work with it. So an
object is stored and retrieved according to a class identifier and the
instance number of objects with that class identifer.

OK, but that means you have a fundamental architectural problem. You are going to have to decide whether to change the architecture or bandage the symptoms. Changing the architecture is probably going to result in a substantial "shotgun refactoring".


So here's the rub that I'm working on now: the instance numbers of the
different objects were assigned based on the order in which the objects
were added to the data structure. So if I add three instances of class
A the first instance added would get instance identifier 1, the next
would get 2 and the last would get 3. Much of the client code within
the same application was written to request a hard coded instance
number of a class when they needed access to that instance.

As I'm sure you guessed by now changing the initialization order of the
product caused many of the instance numbers stored in the data
structure to change breaking the hard coded clients. As a first step to
improving this design I'm trying to replace the implicit assigning of
instance numbers with explicit instance numbers so changing the
initialization order will no longer break the clients.

I think this is mostly a mechanical problem. You simply have to change the way a value (instance number) is assigned and how clients know what it should be to access Find facilities. Others have suggested solutions like ADTs, which is fine. In the end you are making identity a variable rather than a <hard-wired> constant. Just pick a strategy for implementation and do the surgery. That sort of surgery may be tedious but it should be fairly straight forward.


And finally the issue I ran into: I have a class whose instances are
stored in this "one data structure to hold them all" (call it class A),
however this class is created within another class (call it class B) of
which multiple instances are created from within another class (class
C). IOW class C contains 2 instances of B each of which contain an
instance of A. So when creating instances of class A I cannot provide a
simple enumeration of the instance number when adding to the data
structure or the instance numbers will not be unique.

I'm thinking this data structure design is falling apart rapidly but
its so deeply integrated into the product redesigning it may not be
feasible right now. But I'm really stuck on how to create unique
instance numbers (that can then be referenced from within client code)
when the objects to be added to the data structure are created from
within objects that may also have multiple instances.

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.

[C]
| 1
|
| R1
|
| collects
| *
[B]
| 1
|
| R2
|
| collects
| *
[A]

where R1 and R2 are implemented with collection classes. The collection classes then manage the collection (Add/Remove) and provide efficient support of Find semantics. When you identify an identity strategy, it would be naturally implemented in the collection classes for Add, Remove, Find. That decouples the clients from the actual collection management. The basic problem structure is captured in the access restrictions implicit in the relationships. Thus a Client of a C needing a specific instance associated with C would navigate ("walk") the R1 -> R2 relationship path to get to the right set of [A]s. (IOW, whoever instantiates R1 and R2 makes sure the rules of access are obeyed.)

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.

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.

When the objects are properly decoupled through peer-to-peer relationships, an object initiating a collaboration may not need to know or care which object it is collaborating with. It just collaborates with whoever is "on the other end of the line". This dovetails with the identity strategy because the client may treat the identity as a variable value it gets from somebody else. IOW, the client may have no clue who it is actually talking to. But your identity strategy will necessarily depend on the relationship architecture, so if you are going to change the architecture, define that first.


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

  • Java Developer/Powerbuilder Developer, Provo, UT.
    ... Our Client is seeking a qualified Java/PowerBuilder Architect who ... architecture to n-tier java architecture. ... Design, develop, test, document and deploy enterprise-level Java ... Successful candidates will meet and exceed all of the ...
    (comp.lang.java.databases)
  • Java Developer/Powerbuilder Developer, Provo, UT.
    ... Our Client is seeking a qualified Java/PowerBuilder Architect who ... architecture to n-tier java architecture. ... Design, develop, test, document and deploy enterprise-level Java ... Successful candidates will meet and exceed all of the ...
    (comp.lang.java.programmer)
  • IT Architect (.NET, J2EE) - Bank, Toronto, Canada
    ... All responsibilities carried out in accordance with the Code of Conduct and Guiding Principles. ... ยท Support in the develop Technology Frameworks that assist business solutions teams within CLIENT Financial Group to shorten solution delivery cycles and raise the quality of solutions produced ... documentation and communication of technology architecture vision and strategy across the enterprise. ...
    (microsoft.public.dotnet.framework.windowsforms)
  • Passing tokens down multiple layers of web services
    ... I'm facing a challenge in designing a Service Oriented Architecture based on ... WSE 2.0 SP1. ... Is there a way to pass on the token from the inputfilter of a webservice to ... My idea was that as you are in the context of a call from a client, ...
    (microsoft.public.dotnet.framework.webservices.enhancements)
  • Best way to handle this Business Problem
    ... This client loves excel spreadsheets ... ... Program (each program type having its own set of columns). ... I say data structure because I don't want to pin down ... aggregation needs to be good enough to show ... ...
    (microsoft.public.sharepoint.windowsservices)