'. '

Errata 6

From APIDesign

Revision as of 07:38, 8 October 2010 by JaroslavTulach (Talk | contribs)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search

The chapter 6 discusses protected abstract methods and says that removing such method is source compatible (page 89). In fact that was true until Java 5 appeared. However with the newly introduced @Override annotation this is no longer true.

Code from Anagrams.java:
See the whole file.

public abstract class Anagrams extends javax.swing.JFrame implements UI {
 
    protected abstract WordLibrary getWordLibrary();
    protected abstract Scrambler getScrambler();
 
    public void display() {
        initWord();
        setVisible(true);
    }
}
 

If you create a new version of public abstract class Anagrams dropping either getWordLibrary or getScrambler (or both), the @Override annotation in AnagramsWithConstructor will cause the compiler to complain:

Code from AnagramsWithConstructor.java:
See the whole file.

public class AnagramsWithConstructor extends Anagrams {
 
    private final WordLibrary library;
    private final Scrambler scrambler;
 
    public AnagramsWithConstructor(
        WordLibrary library, Scrambler scrambler
    ) {
        this.library = library;
        this.scrambler = scrambler;
    }
 
    @Override
    protected WordLibrary getWordLibrary() {
        return library;
    }
 
    @Override
    protected Scrambler getScrambler() {
        return scrambler;
    }
}
 

Source compatibility is gone. As an API designer of public class Anagrams you don't know whether your users (writing class AnagramsWithConstructor) will use @Override. As a result don't even try to remove protected abstract methods from an API. It was never good idea anyway and since Java 5 it is not backward compatible.

-- Rijk van Haaften, Oct 8, 2010

Personal tools
buy