[omniORB] CORBA vs. Multiple-Inheritance

[Gary D. Duzan]

In Message <000001bdd508$06967420$1753e58c@fritzrh-nt.nawcad.navy.mil> ,
   "Robert H. Fritz" <rfritz@geologics.com> wrote:

=>Hi Everyone,
=>
=>I'm looking for a little OO guidance here ...
=>
=>If I weren't using CORBA, my design would show two classes both decended
=>from a common abstract-class ancestor.  The pure-virtual methods that would
=>be implemented by the decendents would be public.  The methods implemented
=>by the ancestor would be protected.
=>
=>Here's my difficulty.  I would like to have only the public methods appear
=>as IDL interfaces.   How do I declare in IDL or otherwise the relationship
=>of the decendent class to their ancestor? 

   In IDL, you only talk about "interfaces"; the only relationship is
base/derived. An implementation of the derived interface must also
implement the interface of its base, recursively.

=>                                           In IDL I tried declaring
=>(overloading) in the decendent an ancestor's method -- this generated an IDL
=>compilation error.

   This is correct. The "decendent" interface already gets the operations
of its "ancestor", so redeclaring would be redundant and is disallowed.

=>                    If I copy the method definitions to each decendent and
=>not even have an interface for the ancestor, where do I tie the
=>IDL-generated class back to the ancestor?

   It sounds to me like you want to have "abstract" interfaces in IDL
which correspond to abstract classes in you implementation.
Unfortunately, this is not supported in IDL or the C++ mapping.
Generally, you get a concrete stub class for each interface you specify
in the IDL. Even the stub classes for inherited interfaces may not
inherit from one another like you might expect.
   To do what you want, you may consider doing the implementation
separate from the stub classes, then using a "tie" to connect them.
That way you can have whatever implementation structure you wish
without depending on the stub inheritance structure. Not that this
approach is without problems of its own, of course, but it might
help.

					Gary Duzan
					GTE Laboratories