[omniORB] IDL Advice

[Stefan Seefeld]

jiwils - Jimmy Wilson wrote:
> 
> We are implementing a project that will have a Factory object.  The factory
> object will have two methods.  One of those will be create, and the other
> will be destroy.  Create will (based on the type passed to it) create on of
> several objects.  To my knowledge, there are two ways of doing this, could
> anyone give me their advice as to which is the better method?
> 
> Method One (base interface):
> ----------------------------
> 
> interface A
> {
> // empty
> }
> 
> interface B : A
> {
> // lots of methods
> }
> 
> interface C : A
> {
> // lots of methods
> }
> 
> interface ObjectFactory
> {
>         // create method
>         A Create(in string Type);
>         // destroy method
>         void Destroy(in A Obj);
> }
> 
> Method Two (use an IOR):
> ------------------------
> 
> interface B
> {
> // lots of methods
> }
> 
> interface C
> {
> // lots of methods
> }
> 
> interface ObjectFactory
> {
>         // create method
>         string Create(in string Type);
>         // destroy method
>         void Destroy(in string ObjRef);
> }
> 
> It seems to me that Method One is the most object oriented and can get
> around a couple of Obj->Str/Str->Obj function calls.  For those reasons I
> prefer it, but I would like to see if there are any other reasons that
> Method One is better and/or if there are reasons that Method Two is
> preferable.

there are a couple of issues I'd like to raise about your proposition:

* you probably mean repoID when you say IOR above. Once you have an IOR you
  already have the object, no factory is needed (only may be an implementation
  repository or an activation demon).

* you can't have a factory method 'destroy' with the object as in parameter.
  This is because to make sure your object is really one of your own, you'd need
  to provide an equality operator. _is_equivalent has too weak semantics to
  work reliably.

* While the method one would certainly work (the NameService uses a similar
  method to resolve an object of arbitrary type), I prefer more statically typed
  scenarios. Why not a factory with a whole numch of methods, one per type ?

* to follow the last line of thought even further, is it really necessary that
  all the different objects you create have different types ? Or could you get
  along with a single type and merely different implementations ? This would
  be even cleaner from a pure design perspective.

As an example consider this:
I'm working on the Berlin Windowing System where we have 'kits' which are factories
for scene graph objects - 'Graphics'. Here is part of the interface of the LayoutKit,
a kit which produces graphics which's purpose is to pack (lay out) their children.

interface LayoutKit : Kit
{
  Graphic clipper(in Graphic g);
  Viewport scrollable(in Graphic g);
  Stage createStage();
  Grid fixedGrid(in Grid::Index upper);
  Graphic fixedRange(in Grid g, in Grid::Range r);
  Graphic hbox();
  Graphic vbox();
  //...
};

As you can see, the kit in question has a number of methods, each generating
another object type, partly from different interfaces. Depending on the nature
of the specialized object, it may be necessary to derive them from various
interfaces (Grid, Stage, Viewport), or simply use a uniform interface (Graphic)
with different implementations.

The above has proven to be extremely useful in our case, we provide a number of
kits, each for a particular domain of objecs (LayoutKit, FigureKit, TextKit,
WidgetKit etc.)

Best regards,	Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: seefelds@magellan.umontreal.ca

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...