Re: Managing multiple instances

On 28 Apr 2006 14:00:59 -0700, "Benjamin M. Stocks" <stocksb@xxxxxxxx>
wrote:

Hello all,
I'm working on an application where a number of what I will call core
objects are maintained within a single data structure. Each class that
must persist for the lifetime of the application inherits from the same
base class and then adds itself to a data structure of that base class
type.

That sounds like you are using a proxy.

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.

Normally one would use a class variable (in c++ its a static) to hold
the unique instance name.

The problem you will get, is that if the instance name is dynamically
generated - for example by incrementing the class variable as each
object is constructed, then it can be likely that the rest of the
application can have no idea on which instance is which. Only the
creator will have any idea why a piece of data was created and thats
out in the application somewhere.

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.

Never a good idea.
I suspect from how I read it, is that you have persistent references
(perhaps hard coded ) to transient data.

There is an old rule of thumb that says - "Let the resources find you,
dont try and find them". However, in this situation I suspect that
solution will not be possible. Instead I figure there is a need to
decouple the application from the data.

A proxy class encapsulates and hides the data that it contains and
works by providing a single access mechanism to that data which all
code would use.

Simply put, the proxy is the owner of the data you want (its really
called a Master object') and is responsible for the
creation/destruction/ordering of that data.

I do not know why you intend on changing the order of creation, since
you said the application is dependant on that order always being the
same (ie. it expects a certain piece of data to be in a certain
location).

If what you want is a certain piece of data to be assigned to a
specific name, then this will only be possible of the set of objects
is fixed in size and not dynamic in size (ie. you know the maximum
number of objects). I would suggest that this is so, because of the
hard coding of instance names within the program.

If the set is fixed, then the proxy would likely need to contain a
'Map' to translate the applications instance names, to the proxies
internal names - the proxy data can then be moved from an ordered list
to an unordered bag (which is what I think you are trying to achieve
by using explicit names).


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.

One class to hold them all, one class to find them, one class to bring
them all and in the darkness bind them. Sounds like Sauron has been
coding again :)

class C (one) ---> class B (many) --> class A (one)

Is what I think you have.

In this scenario I would probably use two services one being a proxy,
and the other being the interfaces for the application logic to act on
the data. Then keep the instance data as a set of ordered mixins
(structs if you wish). The proxy would store and access the mixins,
the application service would act on those mixins (after retreiving
them from the proxy).

A service is a class without data and a mixin is a class without
methods (a struct kind of). They are commonly used in frameworks.
The idea is that your instance data (mixins) have two services that
work on it, the first is the proxy who has the role of storage and
identification, the second is the application service that contains
the api set to actually manipulate the data.

This gives you a losely coupled form of:

For the data storage
class A (singleton) ---> encapsulate ( class B (many) )

For the application logic
interface C (singleton) ---> class A (one)


Effectively, what happens is that within your application you just
make a call to the application service to get whatever you need done.
As a singleton its visible application wide.

The service behind the scenes communicates with the proxy to get the
appropriate data. You'll find if done correctly, everything regards
to instantiating stuff is delayed til first use of the service, and
only what is actually used is created.

Andy
.

Relevant Pages

  • Re: Managing multiple instances
    ... The data structure had a static ... until now everyone would look and see which identifier ... Then keep the instance data as a set of ordered mixins ... The proxy would store and access the mixins, ...
    (comp.object)
  • Re: Proxy GC
    ... You have to delete the proxy objects in the same order that you do the deletes on your data structure. ... "deleted" objects can be reached from earlier deleted objects since the pointers in the earlier deleted objects aren't changed. ... The RCU+SMR I did used FIFO order. ...
    (comp.programming.threads)