1

電気計算を行うプログラムの Swing 'face' を作成しました。見栄えは良いのですが、基礎となる計算をどのように実装するかについて、当惑するような一連のオプションに直面しているようです。コードが少し長くなってきたので、一般的な言葉で説明しようと思います。

私が取り組んでいるパネルは、電圧降下を計算します。

  1. ユーザーは、計算式のタイプを選択する 2 つのラジオ ボタンのグループから選択できます。
  2. ユーザーは、(7) 異なる変数の値を選択します。そのうちの (3) は、式のいずれかのタイプにのみ存在します。ユーザーは、編集可能および編集不可のコンボ ボックスを選択します。
  3. 追加の (4) 変数があり、ユーザーは、これらを解決する変数をラジオ ボタンで選択します。これらの横には、変数の形式 (フィート、メートルなど) を変更する追加のラジオ ボタンもあります。
  4. 結果はテキスト フィールドに表示され、ユーザーが値を変更するたびに更新されます。

これは多くの処理能力を必要としないと思うので、これはすべてイベント ディスパッチ スレッドで行われます。私はまだスレッドについてあまり知らないので、これは良いことです。

Java とプログラミングに関する私の限られた知識では、これを実装する方法をいくつか考えることができますが、おそらくまだ知らないいくつかの方法があります。私が知っているものでさえ、私にはまだ少し「ぼんやり」しているように見えます。

A. 基本的にパネルに法的な変更が加えられたときに起動するイベント リスナーを使用し、すべての変数をほぼ文字列リテラルとしてモノリシック ロジック クラス コンストラクターに渡します。結果。何をすべきかを理解するのに役立つさまざまなコンストラクター シグネチャを持つことができると思います。ユーザーがパネルを変更するたびに、結果を把握する新しいオブジェクトが作成されます。これは、醜くて扱いにくいようです。

B. 「親ファクトリー」 - (A.) とほとんど同じことを行いますが、変数を引数として抽象クラスのメソッドに渡します。メソッドは何をすべきかを判断し、そのサブクラスの 1 つのインスタンスを作成します。これにより、少なくともアプリケーション ロジックの作業が少し楽になると思います。

C. オブザーバーとオブザーバブル? これがどのように機能するかについては、まだよくわかりません。

D.バインディング？同じこと - 私はまだこれについてあまり知りません。

また、このタイプの計算を別のモジュールにまとめる必要があります。だから私はロジックを再利用したい。

では、どのうさぎの穴から飛び降りればよいのでしょうか? 私は自分自身を隅にコーディングしたくありません。

4

2 に答える 2

0

単一のバッキング オブジェクトを作成し、データが変更されたときにそれを更新します (イベントをリッスンします)。

次に、オブジェクトから変更された計算を要求します (または、データが変更されたときに複数のソースに通知できるようにする場合は、Swing オブジェクトが 'CalculationUpdate' イベントをリッスンするようにします)。

変更ごとに新しいオブジェクトを構築することは、メモリの完全な浪費です。オブジェクトを作成してから無視することは、GC の問題に遭遇する良い方法です。

于 2012-12-09T00:38:02.090 に答える
0

一般に、「ビジネスロジック」（あなたが求めているものと思われる）からユーザーインタラクションロジック（すでに説明したものにうまく対応しているようです）を分離すると便利であることが発見されました。 . 重要なことは、それらを互いに分離しておくことであり、最初にそれらの1つを書くことでそれを行ったようです。ここまでは順調ですね。

別の回答が示唆しているように、「単一のバッキングオブジェクト」は必要ないと思いますが、コードに単一の「モデル」が必要であることに同意します。これは、1 つのクラスまたは複数のクラスである可能性があります。ここで重要なことは、ユーザーへのプレゼンテーションやユーザーとのやり取りに依存せずにロジックを実装することです。ユーザーは任意の方法で数値を提供し、それらをモデルに渡すことができ、モデルはその答えを返し、モデル以外の何かがその答えを提示する方法を決定します。

たとえば、swing アプリケーションの一部であるリスナー (ユーザーが何かを行い、リスナー メソッドが起動する) は、ユーザー インタラクションの一部です。問題の入力を別の方法で取得した場合、それらのリスナーは存在しないため、ビジネス ロジックの一部ではありません。

また、検証はユーザー インタラクション コードの一部だと思います。誰かが数字を入力する方法を変更すると、それらの数字がどのように使用されるかを知らなくても検証が変更されるためです。したがって、計算を行うモデルに数値を入力する前に、ユーザーの入力を検証します。そのコードへの入力は、それを認識していない誰かによって後で再び使用される場合に備えて、すでに検証されていることが期待されることを文書化します。

したがって、誰かが値を変更すると、入力を検証し、無効なデータがある場合はユーザーにメッセージを生成するリスナー (または同等のもの) が起動されることが期待されます。入力が有効な場合は、メソッドを呼び出して計算を行い、値を返し、そのリスナー (または SwingWorker スレッドのリスナー、わからない場合は調べてください) を更新することを期待します。画面上の結果 (これもユーザー インタラクション ロジックでのみ実行する必要があります。

あなたは文字列を渡すことに言及しています。また、検証後にユーザー インタラクション コードをプログラムして、数値を表すはずの文字列値を数値に変換します。これらが入力時の文字列であるという事実は、ビジネス ロジックの一部ではなく、ユーザーがコードと対話する方法の一部です。他の場所から数値を取得したプログラムが計算モデルを使用したい場合、モデルがこのコンテキストでユーザーから文字列を取得するために使用されているという理由だけで、その数値を文字列に変換する必要があるとしたら、それは奇妙で愚かなことです。

お役に立てば幸いです。

于 2012-12-09T03:38:57.410 に答える