1

の特殊なサブクラスJDialog（と呼ばれるBrushListDialog）があり、その中に。がありJListます。リストは、カスタムリストモデル（拡張DefaultListModel<String>）とカスタムセルレンダラー（拡張DefaultListCellRenderer）を使用します。読みやすくするために、これらのクラスをメインクラス内にネストしました。

通常、これらのクラスを静的にします（これは、セルレンダラーに対して行いました）が、リストモデルクラスには次のメソッドがあります。

private boolean showRemoveConfirmDialog(Object elem) {
    int option = JOptionPane.showConfirmDialog(BrushListDialog.this,
            elem + " is a default brush type.\nDo you want to allow the removal of such entries?",
            "Remove", JOptionPane.YES_NO_OPTION, JOptionPane.WARNING_MESSAGE);
    if (option == JOptionPane.YES_OPTION) {
        TYPES.clear();
        return true;
    }
    return false;
}

ご覧のとおり、JOptionPaneの表示位置を決定するために、最上位クラスのインスタンスに依存しています。BrushListDialog.thisもちろん、静的コンテキスト内で呼び出すことはできないため、ネストされたクラスを静的にすることはできません。

これを処理する3つの方法があります（nullの最初のパラメーターに使用することshowConfirmDialogはオプションではありません）。

  1. セルレンダラーを静的に保ちますが、を呼び出せるようにするために、リストモデルを内部クラスにしますBrushListDialog.this。
  2. ネストされた両方のクラスを静的にし、現在のBrushListDialogインスタンスをリストモデルのコンストラクターに渡します。
  3. Swingユーティリティメソッドを使用してコンポーネントを調べ、のインスタンスを見つけますBrushListDialog（これは私の意見ではハッキーです）。

だから私はあなたに尋ねます：それだけの価値のある親ダイアログのインスタンスにアクセスできるようにするために、リストモデルを非静的に保ちますか？

2つのネストされたクラスのソースコード

4

2 に答える 2

1

個人的には、クラスを非静的にリファクタリングする必要があるとは思いません。ここでは、大きなオーバーヘッドについて話しているのではなく、実際には1つの参照だけです。それを考えると、それはより読みやすく、保守しやすいオプションに帰着します。コードをそのままにしておくことは、そのカテゴリに最もよく当てはまると私は主張します。

とは言うものの、本当に静的にしたい場合は、最初のオプションの上に2番目のオプションを提示します。

追加した3番目のものはひどい音に聞こえます-間違いなくその1つから離れてください。

于 2012-12-10T12:39:37.060 に答える
1

JVM に関する限り、オプション (1) と (2) は通常同じです。Java コンパイラは、親クラスと適切なコンストラクタへの参照を暗黙的に作成します。

親クラスの外でそのクラスを使用する必要があるかどうかに基づいて、静的とネストされた決定を行います。そうでない場合は、ネストされたクラスを使用して、親参照コードを明示的に記述する必要がないようにしますが、不適切なアクセス指定子によって作成される暗黙的なアクセス委譲メソッドに注意してください。

オプション (3) は、私が絶対に避けたい恐ろしくもろいハックのように思えます...

于 2012-12-10T12:44:15.027 に答える