Re: Managing multiple instances
- From: "Benjamin M. Stocks" <stocksb@xxxxxxxx>
- Date: 30 Apr 2006 07:54:09 -0700
Normally one would use a class variable (in c++ its a static) to hold
the unique instance name.
The data structure had a static (yes, C++) integer attribute that
contained the identifier to be assigned to the next object added to the
data structure
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.
Absolutely true, until now everyone would look and see which identifier
was assigned to their object and then hard code that identifier into
all of their code that retrieves the object from the data structure.
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).
I don't intend it, its just that if new objects are added to the system
and they are attributes of objects also created at system
initialization, the possibility exists and does happen that the
creation order may change.
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).
I thought about that, using string based names rather that integer
identifiers. At least the string based names would not be susceptiable
to this idea that between system upgrades the integer identifier may
not reference the same object anymore.
class C (one) ---> class B (many) --> class A (one)
Is what I think you have.
Yes. That's the most prevalent example of this issue. Class A is stored
in this data structure so if you create two instances of class C you
wind up with multiple instances of class A and from within the context
of class B there is no way to explicity give class A an identifier that
would be unique and meaningful.
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)
I'm guessing "interface C" is not an interface for class C since that
is a concrete class. Your interface C is the proxy right? I'm missing
how the proxy will assign identifiers to objects as they are added to
the data structure.
Thanks for your help,
Ben
.
- Follow-Ups:
- Re: Managing multiple instances
- From: Sasa
- Re: Managing multiple instances
- References:
- Managing multiple instances
- From: Benjamin M. Stocks
- Re: Managing multiple instances
- From: AndyW
- Managing multiple instances
- Prev by Date: Re: Organizing commands and UI matters
- Next by Date: Re: Managing multiple instances
- Previous by thread: Re: Managing multiple instances
- Next by thread: Re: Managing multiple instances
- Index(es):
Relevant Pages
|