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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With