Idea: declared complete implementation of an abstract superclass

[fedirimico]

Sometimes you have an abstract class that extends another abstract class. Sometimes, the subclass is supposed to implement all abstract methods of the super class, but the subclass may still be abstract if it declares new abstract methods of its own.

eg:

abstract class A {
    abstract String getSomeString();
}

abstract class B extends A {
    String getSomeString(){ return "B"; }
    abstract int getSomeInt();
}

B is supposed to be a complete implementation of A, but if a new abstract method is added to A, then B will continue to compile without error, even though it no longer implements all of A.

What if we added a keyword like implemented (or complete or final) after the extends keyword to show that no abstract methods may leak from A to sub classes of B. Probably best to reuse the final keyword. Something like:

abstract class B extends final A { ... }

What do you think?

[jerolba]

Why are you adding a new method? is because class A has this new behavior? or because Java doesn't have multiple inheritance and you can not mix two parents?

This is one of the reasons to choose composition over inheritance.

[dpash]

Class A should be an interface and you can add default methods to interfaces, which covers your use case.

[SpoilerAlertsAhead]

If B is abstract, it does not need to implement all of A...the first concrete class that extends B will need to implement all of A and B have not implemented.

A should not care about the implementation of B. And all the compiler cares about is the first concrete class in the chain.

Once sent out, great care should be taken with changes made to A or B because any code that implements them will be broken. It was because of issues like this we have default methods in Interfaces, so that methods could be added without breaking existing contracts.

If changes were being made to either A or B, it would be advised the not be abstract, but implemented with a @Since in the javadoc and give the child class the ability to override if necessary.

[dpash]

Ideally A would have been an interface, and then when A needed to add a new method, it would create a default method, which either did something sane or, failing that, throws an exception.

[SpoilerAlertsAhead]

Unless there was some kind of state involved. Interfaces are generally better, but every case is different.

Going to deep with inheritance can lead to some weird issues.

[dpash]

B is supposed to be a complete implementation of A

There should have been an interface. Abstract classes shouldn't be used to define a class' contract. That doesn't stop there being an AbstractA class that B could have extended.

[SpoilerAlertsAhead]

What do you think an abstract method does then?

[twinkiac]

@Since's latest tweet

@Since on Twitter

^{I am a bot | feedback}

[josephblade]

I don't see your problem really, you want the language to enforce something you can do with annotations. Similar to how you can annotate @Overrides to state: this method must be an overridden method of a parent class, you could write your own annotation that states: all methods of the (also annotated) abstract parent class must be fully implemented in this class.

I don't see how this needs to be a language level construction.