4

アクション リクエストをルーティングするために、すべてのコンポーネントに対して 1 つの ActionListener インスタンスを使用したいと考えています。actionPerformed の呼び出しは、setActionCommand を使用して区別できます。

これはお勧めですか？MVC コンテキストでこのアプローチに潜在的な欠点はありますか?

4

3 に答える 3

6

MVC は、M、V、および C を分割することのみを指示します。だから、あなたは自由に行くことができます。

イベント処理メソッド内の切り替えロジックが複雑になりすぎる (数行を超えるなど) 場合は、1 つの巨大なクラスを複数のクラスに分割することを検討してください。より良い概要とメンテナンスを提供します。私を信じてください。単純なリスナーに戻って変更すると、本当に幸せになるでしょう。これはリファクタリングになります。IDE が適切なサポートを提供する場合があります。

だから私のアドバイス：KISS - まず簡単にやって、あなたのものを1つのリスナーに入れます。複雑すぎる場合: もう一度シンプルにして、複数のリスナーにリファクタリングします (これは KISS の別のアプリケーションになります)。

コードをシンプルに保ち、怠惰にクラスを作成しないようにしてください。クラスを作成することは、頭を複雑なコードに戻すよりもはるかに簡単です。常に覚えておいてください: ソフトウェアの作成は 20%、メンテナンスは 80% です。今すぐコードを理解しやすくしておくと、後でメンテナンスが簡単になります。反対のことも当てはまります。

于 2012-08-10T05:32:30.973 に答える
5

「これはお勧めですか?」 私はそうは思わないと思いますが、多くはプロジェクトの規模に依存します。

「すべての卵を 1 つのバスケットに」という言葉が頭に浮かぶと思います。

ifステートメントに新しいアクション ブランチを追加すると、ステートメントのサイズが想像を絶するほど大きくなる可能性があります。プロジェクトの複雑さが増すにつれて、アクション ハンドラーも複雑になります。

潜在的な問題のデバッグも頭痛の種になる可能性があります。

コードのメンテナンスは退屈で誤解を招きやすく、ロジックに新しいエラーが後を絶ちません。

責任の分離ルールを破る (アクション/イベントの管理の責任を、それ自体のオブジェクト/クラス内で分離しようとする必要があります)。

アクション ハンドラーを再利用する方法を探している場合は、代わりにAction API を参照してください。本当に熱心な場合は、Factory を使用して、コード全体でよく知られているアクションを生成できます。これにより、責任の分離を維持しながら再利用が可能になります。

個人的な話ですが、過去 3 年間、私たちのシステムにコア ライブラリを書き込んでこのようなコードを書くのが好きだった経験の浅い卒業生の混乱を解明するのに費やさなければならなかったので、どうかやめてください。壊れやすく、読みにくく、ただの混乱です。

私見は、設計の欠如/または不可能について語っています。

あくまでも私の経験に基づく個人的な意見です

于 2012-08-10T05:20:19.677 に答える
2

  • 最も複雑な方法は、イベントを発生させたEventHandlerを追加することです。これ/これらのイベントは文字列値で比較できます

  • 利点私はパラメータとして値Reflectionを渡す方法を知りません（忘れました）StringJava Classes

  • 不利な点 (私の見解) は最も深い知識を必要とし、Reflection

  • 次善の選択肢が言及される可能性がありSwing Action、優れていてスケーラブルであり、メソッドがで始まることを確認する必要がありますisXxx

  • MVC は、コードをビルドし、 ProprtyChangeXxxを使用して Swing メソッドを介してイベントを配布するためのより適切で正しい方法です。

  • ではなくforJTextComponentsを使用する(多分私が間違っている、おそらく間違った概念、より良い代替手段は何もありません)TextActionProprertyChangeXxx

于 2012-08-10T07:55:32.207 に答える