The general approach I've used in the past involves creating a helper class (anyone want to vote for RFE 4093687? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4093687 ). So we would move to a model like:

public interface iA {
        /**
        * @see BaseImplementation#doFoo(iA)
        */
        public void foo();
}
public interface iB {
        /**
        * @see BaseImplementation#doBar(iB)
        */
        public void bar();
}
public interface iC {
        /**
        * @see BaseImplementation#getDooDad(iC)
        */
        public Object dooDad ();
}

public abstract class BaseImplemenation {
        public static void doFoo(iA) {...}
        public static void doBar(iB) {...}
        public static Object getDooDad(iC) { return new Object();}
}

public class TheClass implements iA, iB, iC {
        public void foo() { BaseImplementation.doFoo(this); }
        public void bar() { BaseImplemenation.doBar(this); }
        public Object dooDad() { return BaseImplementation.getDooDad(this); }
}

Now, you could even go a step further and capitalize on the fact that java only requires that method declarations for interface methods can exist anywhere in the class chain, not just by the implementing class or subclasses, but also by any of it's superclasses. Hence, you could update BaseImplementation to:

public abstract class BaseImplemenation {
        public void foo() { doFoo((iA) this); }
        public void bar() { doBar((iB) this); }
        public Object dooDad() { return getDooDad((iC) this); }
        public static void doFoo(iA instance) {...}
        public static void doBar(iB instance) {...}
        public static Object getDooDad(iC instance) { return new Object();}
}

And add:

public class TheOtherClass extends BaseImplementation implements iA, iB {}

So, TheOtherClass automatically inherits default methods for foo() and bar(). It also has an exposed public method dooDad(), but since TheOtherClass does not implement iC, it will fail with a ClassCastException (unless you are actually working with a subclass that does implement iC!).

Hope this helps!

-Frank


At 01:35 PM 3/28/2005, you wrote:
I'm looking for a technique or pattern to solve the following problem:

I have a class (TheClass) which needs to implement multiple interfaces (iA,
iB and iC).  Each has a default implementation which is sufficient for my
needs (AImpl, BImpl and CImpl).  In C++, you would use multiple inheritance
to solve this problem - inheriting from all three default implementations
in order to inherit all the default behavior.  Of course, this is not
possible in Java (and frankly, I don't miss the complexity of multiple
inheritance).

In the past, I simply implement the interface and pass on method
calls to an aggregated class (e.g. AImpl).  It's simple, but ugly.

I think this could be done with a dynamic proxy, but I'm concerned about
the performance of the heavy use of reflection.  Some parts of our application
are extremely performance-sensitive.  In my case, it is a compile-time
problem -- no run-time variability is required (in terms of the interfaces
implemented).  So using reflection to direct every method call seems
like overkill.

From a language standpoint, it seems to me that some way of combining
the "implements" clause with a contained (aggregated) member would be
the ideal way to solve the problem.  I think of it as
"hyper-aggregation".  For example:

class TheClass implements iA, iB, iC
    {
    AImpl _myvarA provides iA = new AImpl();
    AImpl _myvarB provides iB = new BImpl();
    AImpl _myvarC provides iV = new CImpl();
    }

Thus, the interface iA of AImpl would be exposed as the implementation
of iA for TheClass.  Ideally, one would be able to override the
implementations of each interface within TheClass, when required.
In essence, it is an automatic usage of a dynamic proxy implemented
by the compiler.  The method-call forwarding would be decided by
the compiler, rather than run-time reflection.

Assuming that I am not the first person to run into the problem (nor
the brightest), I have to ask how others solve this problem?  Is there
some obvious problems with my solution above that has kept something
like this from being added to Java?  I can't be the first person to
have thought of it.


TIA, C


-- ------------------------------------------------------------------------- Chris Merrill | http://www.webperformanceinc.com Web Performance Inc.

Website Load Testing and Stress Testing Software
-------------------------------------------------------------------------

_______________________________________________
Juglist mailing list
[email protected]
http://trijug.org/mailman/listinfo/juglist_trijug.org



_______________________________________________ Juglist mailing list [email protected] http://trijug.org/mailman/listinfo/juglist_trijug.org

Reply via email to