1

私はこの本を読んでいます (Head First Object Oriented Design & Analysis)。第 5 章には、それについて他に考えてもらいたい提案があります。本は言う：

「オブジェクト間で異なる一連のプロパティがある場合は、Map などのコレクションを使用して、これらのプロパティを動的に保存します。」

さらに、それを行う理由をいくつか説明します。

「クラスから多くのメソッドを削除し、新しいプロパティがアプリに追加されたときにコードを変更する必要がなくなります」.

このアプローチの利点は理解していますが、ダウンサイズもありませんか? つまり、マップを使用してこれらの情報を格納し (この例では String から Enum へのマップ)、アクセスする getProperty(String) メソッドを提供する場合、このメソッドの呼び出し元は実際にどの String が許可されているかを知る必要があります。これがなんとなく苦手。もちろん、どの入力が許可されているかは javadoc に記載されている可能性があると主張できます。

これは本当にこの種の問題に対処する方法ですか?代替手段はありますか? サブクラスが大量にあるため、継承でこれを行うのは良くないことを理解しています。これらのサブクラスは、新しいプロパティを追加するだけで何かをオーバーライドすることはありません。

4

3 に答える 3

5

個人的Mapには、実際のフィールドの代わりに a を使用するのはひどい考えだと思います。私は、この (アンチ) パターンを広範囲に使用するシステムで作業するという不運に見舞われ、維持するのは悪夢でした。

「将来の証明」のためにマップを使用する理由はまったくありません。新しいメソッドを追加する必要を回避できるという議論はばかげています。特に、新しいフィールドを追加するには約20回のキーストロークが必要であり、ゲッターとセッターをさらに3回追加する必要があると考える場合はなおさらです。 -4回のマウスクリック。得られるものは何もなく、失うものは型の安全性とコンパイル時間のチェック、何をいつ設定するかを制御および監視する機能であり、カプセル化の原則を破るという事実は言うまでもありません。

また、Java 言語自体の開発は、コンパイル時のチェックにますます移行しており、enum とジェネリックがこの方向の最も明白な例であることにも注意してください。すべてを捨てるのは、1.3～1.4の時代よりもさらに悪いことです

マップは、何かが真に動的である場合にのみ使用する必要があります。つまり、コンパイル時にキーのリストを知る方法がない場合です。

于 2011-02-17T22:51:22.280 に答える
2

メソッドを実装して、値をキーとしてgetProperty受け入れることができます。enumこれにより、有効なキーをユーザーに示す簡単な方法が提供されenumますenum。確かに、継承階層enumがあるとややこしいので、オリジナルを変更する方が簡単かもしれません。enum

于 2011-02-17T22:50:56.180 に答える
1

はい、データを取得するにはキーを知っている必要があります。いいえ、これによって根本的な変化が生じることはありません。クラス階層を使用した場合は、呼び出すクラスとメソッドの名前を知っている必要があります。

事前に名前を知らなくても、マップ内のアイテムを使用できることに注意してください。マップを反復処理して、(たとえば) ユーザーに値を表示し、変更を許可し、特定のキーを特定の設定に適用できるようにすることができます。 .

これが必ずしも良いアイデアだと言っているわけではありませんが、良いアイデアかどうかに関係なく実行できます。

于 2011-02-17T22:51:30.973 に答える