Re: Design question: polymorphism after object creation
On Mar 29, 1:34 am, Marcel M=FCller <news.5.ma...@spamgourmet.com>
wrote:
Balog Pal wrote:
"Marcel M=FCller" <news.5.ma...@spamgourmet.com>
I am seeking for a neat solution for the following problem:
There are objects of different types with a common base
class, let's say folders and files (although that does not
completely hit the nail on the head). These objects have a
common primary key, the full qualified path. But the
polymorphic type of the objects emerges only *after* the
object has been referenced. See below.
[...]
I get this, but the following seem contradictory, especially
the observer part. If the object is not there yet why on
earth is it observed?
The object is existing, but not specialized. You may request
different kinds of information. This triggers a worker thread
to obtain the requested information. If the object is not yet
specialized (e.g. File or Folder) the first step is to
determine the object type. This may require an analysis of the
file content or the http object. Than an instance of the
matching class is instantiated and this class fills the
requested kind of informations. Once completed, the observer
is notified that the information is now available. If some
information is available fast and other information take
longer the event may also fire twice with different flags.
Will the object be called on to change its type later, once it
has established the type the first time. If not, I'd certainly
try to defer actual creation until after the type has been
established. If you can't, or if you need to change the type
later, there's always the letter/envelop idiom. But I have a
sneaking suspicion that what you actually need is to use the
strategy pattern. You're object isn't really polymorphic with
regards to everything (the handling of the observer, for
example); what you want to do is use a delegate for the
polymorphic part, which will only be allocated once the real
type is known (and which can be freed and reallocated with a
different type, if necessary).
In the current implementation there is a hard-coded function
that guess the object type from the PK without any I/O. So
File and Folder in the example can derive from Base. But this
guess sometimes fails. This results in an object with invalid
state.
From my limited understanding of the problem, I'd have
something like:
map<string, shared_ptr<Base> > repository;
Yes, similar. But the PK is intrusive part of the object. So
it is more like set<int_ptr<Base> > repository;
From the sound of things, these objects have the logical
equivalent of a static lifetime (i.e. they are created on
program start-up, and live until program shutdown). If this is
the case, why do you want a smart pointer? It doesn't buy you
anything, and it sends the wrong message to the user. (If you
use the strategy pattern, an std::auto_ptr or a
boost::scoped_ptr in the base object might make sense,
especially if you have to change the strategy dynamically.)
As the only info up front is PK, in this phase you just put
that in the map, the ptr is null, signaling the not-accessed
state.
Even an object, that is not fully complete, has some basic
properties. It may be selected, it may be referenced, it has
a changeable display name and so on. NULL is not sufficient.
In other words, your base class has some behavior. Logically,
this means either the template method pattern or the strategy
pattern---the latter means that you can defer the decision, and
change the implementation at will.
[...]
A union with a few types and a stable common base class would
be nice. If the base is virtual, the memory layout could
match the requirements in theory - but only in theory.
Like this:
+------------------------+
| Base |
+-------+--------+-------+
| File | Folder | Other |
+-------+ | |
+ free | +-------+
+-------+--------+-------+
This could turn into 4 different classes (if Base is not
abstract) without the need to change the Pointer to Base.
This can be made to work, but only if there are no pointers to
the object which outlive the change of type. In other words, if
you use some sort of smart pointer, with an additional
indirection so that there is only one instance of the pointer to
the actual object, and if all of the type changes go through the
smart pointer---the function which changes the type should
return this, and the smart pointer use the return value to
"update" its pointer.
Quite frankly, it sounds like a maintenance nightmare. I'd go
with the strategy pattern.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34