Changing the access level of a framework class/method

Question

In this given example, AbstractAnimal has lots of implementations outside the framework. The framework, however, is refactored so that now WalkingAnimals exist. It's intended that Dog, amongst all other animals, will now inherit WalkingAnimal instead. For the sake of example, there are no animals that don't walk. All inheriters should be refactored.

This is a Java framework, so I'll be referring to it as such. But feel free to interpret the question more generally. Because it's quite large, we would like our IDE to provide some kind of indication that the classes that currently inherit AbstractAnimal should be changed. Therefore we thought of the @Deprecated annotation. However, the framework itself will then throw warnings, so it must not be the cleanest method.

In essence, there's classes and methods whose access level will change so that only the framework will be able to use it. We'd like to announce this in the to-be-refactored classes in a manner as clear as possible (such as warnings and strikethroughs provided by @Deprecated). Our IDE is IntelliJ IDEA and we're working with Java 1.8.

We're looking for some kind of automatic task generation in the sense that developers can take a look at a list of warnings and know what they'll still need to change. Also bossman would like to see progress being made, so making these countable would be a great plus.

Thank you in advance for any advice.

Answer 1

What you could do is add an abstract dummy method to AbstractAnimal called youShouldNotExtendAbstractAnimalDirectly() that only has an implementation in WalkingAnimal. This will cause a compile failure in Dog, and when the developers try fixing it they'll run into that method, and either take the hint or shoot themselves in the foot.

Answer 2

You could just give the walk method to the AbstractAnimal class, with a default implementation of throwing an OperationNotSupportedException.

public void walk() {
    throw new OperationNotSupportedException();
}

It really depends on the circumstances whether this is a good idea.

EDIT: To be more exact, as Jeroen points out, you'll only find out whether the new method is properly implemented at run time. Therefore, it's best to catch that exception wherever it is used; the more often you have to do that, the less desirable this solution is.