What are the alternatives to "overriding a method" when using composition instead of inheritance?

Question

If we should favor composition over inheritance, the data part of it is clear, at least for me.

What I don't have a clear solution to is how overwriting methods, or simply implementing them if they are defined in a pure virtual form, should be implemented.

An obvious way is to wrap the instance representing the base-class into the instance representing the sub-class. But the major downsides of this are that if you have say 10 methods, and you want to override a single one, you still have to delegate every other methods anyway. And if there were several layers of inheritance, you have now several layers of wrapping, which becomes less and less efficient. Also, this only solve the problem of the object "client"; when another object calls the top wrapper, things happen like in inheritance. But when a method of the deepest instance, the base class, calls it's own methods that have been wrapped and modified, the wrapping has no effect: the call is performed by it's own method, instead of by the highest wrapper.

One extreme alternative that would solve those problems would be to have one instance per method. You only wrap methods that you want to overwrite, so there is no pointless delegation. But now you end up with an incredible amount of classes and object instance, which will have a negative effect on memory usage, and this will require a lot more coding too.

So, are there alternatives (preferably alternatives that can be used in Java), that:

• Do not result in many levels of pointless delegation without any changes.
• Make sure that not only the client of an object, but also all the code of the object itself, is aware of which implementation of method should be called.
• Does not result in an explosion of classes and instances.
• Ideally puts the extra memory overhead that is required at the "class"/"particular composition" level (static if you will), rather than having every object pay the memory overhead of composition.

My feeling tells me that the instance representing the base class should be at the "top" of the stack/layers so it receives calls directly, and can process them directly too if they are not overwritten. But I don't know how to do it that way.

[EDIT] It seems that many people reading this question think that I am debating if I should use Composition or Inheritance, and that "guiding" me to the one or the other will solve my problem. This is not the case. I always use inheritance when I can, for the simple fact that composition requires more coding, and also more memory. No need to convince me that inheritance is not evil.

I have a very good reason to want to use composition. I want to create a system that model domain objects that can "change nature" over time. That is they can both gain and loose functionality/properties over time, as a result of some actions. This is a lot more natural when modeled as composition.

If the components that can be dynamically added and removed where composed only of properties, it would be easy. In fact I have already found 14 different possible designs that support that case, with varying compromise on code complexity, memory usage, and speed.

The real problem comes when all those components need to be aware of each other, and talk to each other. This is not required when they are just "beans" (in the Java sense). I want to know if there are any, and hopefully several, ways of allowing the components to talk to each other, and more specifically how to have several components of the same type, where one serves as base-class and the others progressively override some of it's methods.

I can see two ways to simulate the overriding present in inheritance.

The first is to have a base component, and all overriding components are built as wrapper on top of another component of the same type. Like that, you can choose at runtime which hierarchy of components you want. This is like pipes and filters. But the problem is that with inheritance, not only can the derived class call methods of the base class, but it works the other way around too. A base class can declare a pure virtual method, which is implemented by the sub-class, and the base class can call this method. I don't see how to accomplish that using whole component wrapping. Also, if we have N inheritance/wrapping layers, then calls to method of the base component then gets N level of delegation, even if the method was not overwritten by any of the wrapping components.

The other alternative, like I said in "One extreme alternative ...", is to do it like above, but forcing each component to contain a single method. In that case we solve the problem of the base-class not seeing/calling the methods of the derived classes, for all methods, except it's own method. So it works now correctly for all cases except for recursion. But the price we pay in memory consumption is high, at least in Java. And Java isn't "functional", so there is a lot of syntax overhead to turn every object method into an individual object.

If there any better alternatives then the two mentioned above, I would like to know about it.

Answer 1

"favor composition over inheritance" doesn't mean never use inheritance, but just don't use inheritance when composition will work. IMO, the need of overwriting justifies the use of inheritance.

Answer 2

A way to reduce the memory overhead of your second solution is to add one level of indirection and push the behavior in an object which would be shared by all the objects which share the same behavior (more or less like prototype based language behaves). As you seem to want a very dynamic behavior, finding it could be difficult if the objects have to make evolve their behavior independently.

class Composed { 
public:
    void foo() { proto->foo(this); } // with a proto member, less overhead per call, maintaining it could be hard
    void bar() { protos[state]->bar(this); } // with a static map allowing to decode a state member
    void qux() { findProto(this)->qux(this); } // find it however you want
    // you need to handle the data part
};

Answer 3

If you're composing your data, why not also compose your methods? Many languages have a notion of a function as an object, or a function pointer. Your composition target could have methods which are defined as properties and these could be recomposed as you see fit. Here's an example in my primary language, C#:

public class ComposedClass
{
    public Func<string, string> Format { get; set; }

    public ComposedClass()
    {
        Format = s => s.ToUpper();
    }
}

This class has a default implementation of Format which will convert the string to upper case. We could provide an alternative implementation which does something else.

[TestFixture]
public class Tests
{
    [Test]
    public void Default_implementation_returns_FOO()
    {
        var composedObj = new ComposedClass();

        var result = composedObj.Format("Foo");

        Assert.That(result, Is.EqualTo("FOO"));
    }

    [Test]
    public void Alternative_implementation_returns_foo()
    {
        var composedObj = new ComposedClass();
        composedObj.Format = (string s) => s.ToLower();

        var result = composedObj.Format("Foo");

        Assert.That(result, Is.EqualTo("foo"));
    }
}

You would have to implement appropriate guards around set_Format of course, and you would have to explicitly pass around an alternative to this if it is required.

It's worth pointing out that in reality, I would probably do what @AProgrammer is suggesting, and use inheritance anyway, but since you asked what are the alternatives, here is an alternative!

Answer 4

Consider using a dynamic language (e.g. Python) instead of Java, if possible. That way you get the dynamic language and its features from the beginning, instead of having to implement it yourself.

Answer 5

Delegation

Its very used in Java in the Streams classes, but , applies to other programming languages, and frameworks, as well.

In the following "dummy" example, there are several interfaces, and several classes that support those interfaces.

One of that clases, its composed by another classes, delegates their functuonality, by using their composite fields methods.

public interface StreamInterface
{
  bool canRead();
  bool canWrite();
  bool canSeek();
}

public interface ReaderInterface extends StreamInterface
{
  void read(byte[] Buffer, int MaxSize);
}

public interface WriterInterface extends StreamInterface
{
  void write(byte[] Buffer, int MaxSize);
}

public class ReaderClass extends ReaderInterface
{    
  bool canRead() { ... }
  bool canWrite() { ... }
  bool canSeek() { ... }

  void read(byte[] Buffer, int MaxSize) { ... }
} // class ReaderClass

public class WriterClass extends WriterInterface
{    
  bool canRead() { ... }
  bool canWrite() { ... }
  bool canSeek() { ... }

  void write(byte[] Buffer, int MaxSize) { ... }
} // class WriterClass

public class ReaderWriterStreamClass
  extends
    ReaderInterface,
    WriterInterface
{
  public ReaderInterface Reader;
  public WriterInterface Writer;

  void read(byte[] Buffer, int MaxSize)
  {
     Reader.read(Buffer, MaxSize);
  }

  void write(byte[] Buffer, int MaxSize)
  {
     Writer.write(Buffer, MaxSize);
  }    
} // class ReaderWriterStreamClass

In this example, we can use "ReaderClass" & "WriterClass", to support the required methods, but, can also be replaced by other classes.

Cheers.

Answer 6

I have come to a working example that shows the properties I desired from the solution. It is somewhat unwieldy, but that is always the case in static languages when using composition to do what inheritance was made for (IMO).

The idea is that you simulate a virtual dispatch table using a singleton class instance, where you have one field per method, pointing to the domain interface. So you can set each field of the VDT to a different implementation if you want, and the implementations are decoupled. And in your real object, you just need one extra reference to that VDT, which is immutable and shared by all your instances.

Here is the code example

Answer 7

Have one or more optional delegate properties in the base class, then have it call the delegate's method from the base method, if present and where applied. Simplistic code in ECMAScript (can be translated to most modern languages):

class BaseClass {
    method() {
        // optional code before

        if (this.delegate) {
            this.delegate.method();
        }

        // optional code after
    }
};

With this approach, you'll have the option to dynamically plug any kind of delegate to instances of the base class.

You can even have code in the base class' own method, regardless of what the delegate does after/before. This can have its own advantages as opposed to having each method that overrides the base class' method calling super() when using inheritance.

For more sample code that use this technique, please refer to this source code.