I have been thinking about inheritance vs composition a bit lately. A key point of inheritance is implicit reuse.

Lets say we want to extend the behavior of a function on a class A. In a language with inheritance, it is trivial.

class A {
  func doSomething() { }
}

class Ae extends A {
  func doSomething() {
    super.doSomething();
    // we do something else here
  }
}

With composition and an interface we, embed A within Ae and call the method and, within expectation, have the same result

interface I {
  func doSomething();
}

class A implements I {
  func doSomething() { }
}

class Ae implements I {
  A a;
  func doSomething() {
    a.doSomething();
    // do someting else
  }
}

This works great... until we run into issues where the interface I is long and in order to implement it while only modifying one method, we need to write boiler plate in Ae, calling A as we go explicitly. Inheritance eliminates the additional boiler plate (there may be other headaches including private data fields and methods, etc, but lets assume the extension does not need access to that).

Idea: In order to eliminate the need to explicit inheritance, we add language level support for delegates for interfaces.

interface I {
  func doSomething();
  func doSomething2();
}

class A implements I {
  func doSomething() { }
  func doSomething2() { }
}
// All methods in I which are not declared in Ae are then delegated to the
// variable a of type A which implements I. 
class Ae implements I(A a) {
  func doSomething() {
    a.doSomething();
    // do someting else
  }
  // doSomething2 already handled.
}

We achieve the reuse of inheritance without an inheritance hierarchy and implicit composition.

But this is just inheritance?

Its not though. You are only allowed to use as a type an interface or a class, but not subclass from another class. You could chain together composition where a "BASE" class A implements I. Then is modifed by utilizing A as the default implementation for class B for I. Then use class B as default implementation for class C, etc. But the type would be restricted into Interface I, and not any of the "SUB CLASSES". class B is not a type of A nor is class C a type of B or A. They all are only implementing I.

Question:

Is this worth anything or just another shower thought? I am currently working out ideas on how to minimize the use of inheritance over composition without giving up the power that comes from inheritance.

On the side where you need to now forward declare the type as an interface and then write a class against it, there may be an easy way to declare that an interface should be generated from a class, which then can be implemented like any other interface as a language feature. This would add additional features closer to inheritance without inheritance.

Why am I against inheritance?

Inheritance can be difficult? Interfaces are cleaner and easier to use at the expense of more code? Its better to write against an Interface than a Class?

Edit 1:

Both-Personality7664 asked regarding how internal function dependencies within the composed object would be handled.

A possible solution would be how the underlying dispatching works. With a virtual table implementation, the context being handled with the delegate would use a patched virtual table between the outer object and the default implementation. Then the composing object call the outer objects methods instead of its own.

// original idea result since A.func1() calling func2() on A would simply call A.func2()
Ae.func1() -> A.func1() -> A.func2()

// updated with using patched vtable // the table would have the updated methods so we a dispatch on func2() on A would call Ae with func2() instead of A. Ae.func1() -> A.func1() -> Ae.func2()

Edit 2:

Mercerenies pointed out Kotlin has it.

It seems kotlin does have support for this, or at least part of it.