Question

Let’s say I’m extending JFileChooser and making an easy-to-use version, which I’m calling SimpleFileChooser.

It is structured such that it can either be DIALOG_TYPE_OPEN or DIALOG_TYPE_SAVE — hence, JFileChooser‘s showOpenDialog() and showSaveDialog() methods are superfluous. I replace them with a method called showDialog() which returns a boolean, but this is where I find myself in a dilemma:

Should I override the open/save methods and add @Deprecated tags to
them so that the API user knows they’ve been superseded? Would that
violate the annotation’s original purpose?

Or would a notice in the documentation be enough? If so, where should
this notice be placed: in the class summary or above the overridden
methods? Should I even override the methods in the first place?

Thanks in advance.

Answer 1

I think you are actually building a facade, a simplified version of already existing API. Thus instead of inheritance you should use composition. Hide the original JFileChooser inside your new class and provide simpler API.

As a last resort you can provide public JFileChooser getRaw() method to access wrapped object if some other code needs it.