4

私が拡張JFileChooserして使いやすいバージョンを作成しているとしましょうSimpleFileChooser。

DIALOG_TYPE_OPENorのいずれかになるように構造化されているDIALOG_TYPE_SAVEため、とメソッドは不要です。それらをブール値を返すメソッドに置き換えますが、ここでジレンマに陥ります。JFileChoosershowOpenDialog()showSaveDialog()showDialog()

open/save メソッドをオーバーライドして@Deprecatedタグを追加し、API ユーザーがそれらが置き換えられたことを認識できるようにする必要がありますか? それは注釈の本来の目的に違反しますか?

または、ドキュメントの通知で十分でしょうか? その場合、この通知はどこに配置する必要がありますか: クラスの概要またはオーバーライドされたメソッドの上? そもそもメソッドをオーバーライドする必要がありますか?

前もって感謝します。

4

2 に答える 2

8

実際には、既存の API の簡略化されたバージョンであるを構築していると思います。したがって、継承の代わりに構成を使用する必要があります。オリジナルを新しいクラス内に隠し、JFileChooserよりシンプルな API を提供します。

最後の手段として、public JFileChooser getRaw()他のコードが必要とする場合、ラップされたオブジェクトにアクセスするメソッドを提供できます。

于 2012-11-05T21:07:35.970 に答える
1

@Deprecated は、将来削除されるため、その特定のクラスまたはメソッドを使用しないことを意味します。その注釈はそのために設計されています。手短に答えると、API ユーザーにメソッドを使用させたくない場合は、@Deprecated を使用する必要があります。そうしないと、将来のビルドで削除するメソッド/クラスをまだ使用しているユーザーになり、更新時にプロジェクトが壊れてしまうためです。

于 2012-11-05T21:08:21.660 に答える