3

Java Swingの初心者として、ユーザーインターフェイスロジックをドメインロジックから分離するのに問題があります。

JLabel、JTextField、およびJButtonを含むJFrameを備えた小さな（些細な？）Swingアプリがあります。JButtonを押すと、JFileChooserダイアログがポップアップします。ファイルを選択した後、JTextFieldにはファイルへの絶対パスが含まれます。これまでのところ、壮観なものはありません。次に達成したいのは、ファイルのこの絶対パスが、選択が行われ、JTextFieldが更新されたとき（ファイルが選択されるたびに）にファイルの実際の処理を処理するファイルマネージャークラスに「注入」されることです。 JButtonを使用）。

私が持っている質問：

  1. ファイルの読み取りを開始するタイミングをファイルマネージャーに通知するにはどうすればよいですか？（たとえば、そのファイル内の行数を数えます）
  2. UIレイヤー内で最小限の情報が共有されるようにドメインレイヤーを実装するにはどうすればよいですか？UIにファイルマネージャーインスタンスを追加する必要がありますか？
  3. JTextFieldの値をファイルマネージャーへの参照として使用する必要がありますか、それともJButtonアクションを使用して値をファイルマネージャーに設定する必要がありますか？つまり、JTextFieldのpropertychangelistenerを使用するか、JButtonのactionlistenerを使用しますか？
  4. filebeanを使用して、ドメインレイヤー内にファイルの絶対パスを保存する必要がありますか、それともファイルマネージャーに直接挿入する必要がありますか？違いは次のとおりです。プロパティ変更リスナーを使用すると、UI入力が変更されたときにファイルの絶対パスの値を更新できますが、コンストラクターまたはセッターを使用して値を直接挿入する場合は、ファイルマネージャーで変更を処理する必要があります。 filebeanの変更を処理する代わりに。
  5. ドメインロジック内のファイルマネージャー内のUIで使用されているfilebeanを参照するにはどうすればよいですか？
  6. ドメインロジックはビジネスロジックと同じですか？つまり、ファイルマネージャクラスはパッケージwhatever.b-logicにあり、filebeanクラスはパッケージwhatever.domainにある必要がありますか？

アプリケーションはいくつかのパッケージに分かれています。

  • 何でも：メインクラス
  • 何でも。プレゼンテーション：スイングのもの
  • 何でも.domain：データのもの
  • whatever.logic：アプリケーションロジック

私は十分に明確であることを願っています...

物事を片付けてくれてありがとう。

4

2 に答える 2

4

個人的には、この種の問題に取り組むときは、再利用可能性と責任（誰が何に対して責任があるか）を主要な要件として検討します。

つまり、データの出所や行き先を気にしないようにモデルを設定し、それを実現するためのインターフェイスアクセスを提供するだけです。

すべての要素を相互に接続するために、私はクライアントにイベントを提供するモデルに依存しています。モデルは誰が知りたいのかを気にせず、必要な機能を提供するだけです。したがって、クライアントにフィードバックを提供するために、私は一連のリスナーに依存します。

リスナーを特定のジョブに分割します。たとえば、ファイル読み取りの通知はそれ自体のリスナーであり、モデルへの変更（追加/削除/更新）ファイルBeanは別のものになります。他の通知には別のリスナーが必要になります。これにより、実装が実際には知りたくないモンスターリスナーを作成できなくなります。

モデルに値を設定するために、私はプロパティセッター/ゲッターの側で誤りを犯します。これにより、モデルが実装から切り離されます（モデルを自動化された方法で使用している場合はどうなりますか??）

内部データは、可能であればモデルによって最適に管理されます。つまり、モデルが管理しているファイルBeanのプロパティを変更する場合、モデルは変更を監視して処理できる必要があります。そうは言っても、将来的にはダムモデルが必要になる可能性があります。このモデルでは、一連のファイルBeanをバッチ更新してから、モデルにそれ自体を更新するように依頼できます。

私は個人的に、自己監視を提供できる実装を少なくとも1つ提供しながら、モデルを外部で更新する手段を提供するでしょう。これにより、適切な状況に適したモデルを柔軟に選択できます。

ここにはメモリリークの危険性もあります。リスナーが不要になったときにファイルBeanからリスナーを適切に削除しないと、後でBeanがガベージコレクションされるのを防ぐことができます。

可能な場合は、インターフェースを使用してください。これにより、これらのモデルをまとめようとするときに大きな柔軟性が得られます。

あなたが説明することについては、ファイルマネージャーがファイルビーンのコンテナーになるように、ファイルビーンがファイルマネージャーの責任になることを許可します。

プロジェクトの規模と、将来コードを再利用する方法によっては、コードのレイアウトに大きな影響を与えます。

私は通常、UIコードをUIパッケージとサブパッケージに入れますが、それは私だけです。私はインターフェースコンテンツを実装コンテンツから分離する傾向があります（通常は物理的に別々のJarファイルにありますが、これも私です）。つまり、必要に応じて（または必要に応じて直接）実装を実際にインスタンス化するために、ある種のファクトリを使用して、インターフェイスライブラリと使用している可能性のある実装のみを含める必要があります。たとえば、JDBCドライバを考えてみてください。

あなたは責任範囲に目を向けたいと思っています。あなたの説明から、ファイルBeanはファイルマネージャーの責任範囲に含まれていると感じているので、この2つを結び付けます。

それが私の見解です

于 2012-07-16T23:29:08.233 に答える
4

ここにいくつかの提案があります：

  • ここSwingWorkerに示されているを使用して、進行状況を聞きながらGUIをアクティブに保ちます。

  • ここActionに示されているを使用して、機能をカプセル化します。

  • File便利なクロスプラットフォームの抽象化を使用します。クロスプラットフォームではない部分を引き出すのではなく、新しい抽象化を構成するために使用します。

補遺：「スイングアーキテクチャの概要」とその回答も参照してください。

于 2012-07-17T00:03:18.230 に答える