Do any OO languages support a mechanism to guarantee an overriden method will call the base?

Question

I think this might be a useful language feature and was wondering if any languages already support it.

The idea is if you have:

class C
  virtual F
     statement1
     statement2

and

class D inherits C
  override F
     statement1
     statement2
     C.F()

There would be a keyword applied to C.F() such that removing the last line of code above would cause a compiler error because it's saying "This method can be overridden but the implementation here needs to run no matter what".

Answer 1

Yes, they do. It is called Scandinavian model of OO, it is used for example in Simula (the other OO model which is widespread and taken as granted now, is American model). In Scandinavian model, you are not overriding, but supplying sub-behaviour.

in Superclass's method foo:

some-code-before
INNER // this is the actual Simula keyword
some-code-after

in Subclass' method foo:

some-code-in-subclass

If you call Superclass' instances' method foo, only some-code-before and some-code-after happens (INNER does nothing), but if you call Subclass' instances' foo, it does some-code-before, some-code-in-subclass and then some-code-after.

Answer 2

No language I know of enforces calling the overridden method. Indeed, some languages allow overriding methods that are not overridable (such as using the new keyword in C#). However, there are two ways of approaching this.

The first is to create an unoverridable method (e.g. one that lacks the virtual keyword in C# or one that has the final keyword in Java) that calls an overridable one that cannot be called from outside the class (e.g. protected in C#, Java or C++).

class C
  A
     statement1
     F
     statement3

  protected virtual F
     statement2

and

class D inherits C

  protected override F
     statement4
     C.F()

Classes overriding C are free to override the F and modify its behavior but callers from outside the class only access it through A.

Edit: As others have pointed out, this is called the Template method pattern.

The second way is to use a language that enforces preconditions and postconditions specified in the base class, like Eiffel or C# with Code Contracts. It will not force the base class to be called but the overridden method can be forced to perform the same statements. Using aspects may also help if the language allows aspects to be inherited.

Answer 3

Not really part of the language, but the FindBugs static code analyzer for Java has an annotation OverrideMustInvoke that a developer can add to a method, and which will cause FindBugs to show an error if it finds an overriding method that doesn't call the super implementation. It even allows specifying whether the call must be first or last in the overriding method.

Answer 4

Requiring to call a superclass method is an anti-pattern. If it isn't enforced at compile time it is error-prone, which is why you are looking for a language construct that checks for it.

There is a way that is supported in all OO languages: The template method pattern. Here, you make the superclass method not overridable, and in it you call a overridable method. The subclass then can override this method to add functionality:

class super {
  public final void doSomething() {
    doSpecialthing();
    doMore();
  }
  public void doSpecialthing() {
  }
}

Depending on the location of the call to the overridden method it even allows to determine the order of execution, which with the ordinary super call is at will of the subclass implementer.

Answer 5

The closest pattern I can think of is self-subscribed events. It's a bit cumbersome, and not at all intuitive for the coder, but achieves the goal.

class C
{
    public void F()
    {
        ...
        OnF()
    }

    protected event OnF
}

class D : C
{
    public D()
    {
        base.OnF += this.F
    }

    private void F
    {
        ...
    }
}

Answer 6

Lisp machine "flavors" allowed methods with type "before" "after" and "around" the inherited main method.

Answer 7

While not a bad idea in theory, it does have the negative side-effect of constraining my options when implementing D. For example, what if (for some unfathomable reason), it's more convenient to call the superclass implementation of F from some other method:

class D inherits C
    override F
        statement1
        statement2
        G()
    G
        statement3
        C.F()
        statement4

Under your scenario, I imagine the compiler would flag the implementation of F in D, even though it does (indirectly) call C.F().

Basically, what you've described is a possible mechanism to help the compiler recognise when a contract on classes inheriting from C is violated. My point is that, while that's a great thing, it shouldn't come at the expense of limiting how I can implement my subclass.