7

私の現在のアプリケーションには、約 15 個のアクションが JFrame 内のフィールドとして格納されている JFrame があります。各アクションは匿名クラスであり、一部はかなり長いものです。

おそらくアクションと呼ばれるサブパッケージ内で、アクションを独自のクラスに分割することは一般的ですか?

そうでない場合、この複雑さは通常どのように緩和されているのでしょうか?

ありがとう

4

3 に答える 3

8

アクションが再利用可能 (キーボード ショートカット、他のメニュー、他のダイアログなどから) である可能性があり、特に (UI ではなく) 基礎となるモデルで直接動作できる場合は、一般的に優れています。それらを匿名クラスとして持たないでください。

代わりに、個別のパッケージを作成し、それぞれにクラスを作成してください。

多くの場合、これらを直接インスタンス化するのではなく、定数を定義し、アクションのセットを初期化して返すある種のマネージャーを用意することも理にかなっています。これにより、たとえば、異なるバージョンで異なるアクション セットを提供したり、特定のアクションのみを設定したりできます。内部リリース用。

最後に、アクションをクラス階層にリファクタリングできるかどうかを確認します。多くの場合、コードの複製を節約し、堅牢性を追加するのにも役立ちます (たとえば、アクションを実行する前に特定の条件をチェックします)。

于 2009-01-15T19:59:51.067 に答える
4

それは通常、私が行う方法です。各アクションは、必要なリソースを取得できるように、「アプリ」オブジェクトへの参照を持つ独自のクラスを取得します。私は通常、すべてのアクションを保持するアクション マネージャーを持っているので、それらにアクセスする場所が 1 つだけでなく、有効化などを更新する場所も 1 つあります。

最終的にはこれも手に負えなくなり、その時点で Eclipse RCP、NetBeans フレームワーク、JIDE などのアプリ フレームワークの使用を検討する必要があります。これは、ユーザー定義のキーマップなどをサポートしたい場合に特に当てはまります。

于 2009-01-15T19:49:43.990 に答える
2

私がやっていることは、アクションクラスのパッケージ（実際にはパッケージツリー）を作成し、コンテキストに従って各クラスをインスタンス化することです。私のアクションクラスのほとんどすべては、コンテキストを取得するための抽象メソッドを備えた抽象です（alaSpring）。

public abstract class CalcAndShowAction extends AbstractAction {
    //initialization code - setup icons, label, key shortcuts but not context.

    public void actionPerformed(ActionEvent e) {
        //abstract method since it needs ui context
        String data = getDataToCalc();

        //the actual action - implemented in this class, 
        //  along with any user interaction inherent to this action
        String result = calc(data);  

        //abstract method since it needs ui context
        putResultInUI(result);
    }
    //abstract methods, static helpers, etc...
}

//actual usage
//...
button.setAction(new CalcAndShowAction() {
    String getDataToCalc() {
        return textField.getText();
    }

    void putResultInUI(String result) {
        textField.setText(result);
    }
});
//...

（間違いをお詫びします。IDEではなく、このテキストボックスに手書きで書きました）。

于 2009-01-15T20:34:27.923 に答える