1

特定のオブジェクトを別のオブジェクト内に構成する理由はたくさんあります。一部の学派は、プログラムを特定の方法で設計する理由を明示しています。たとえば、「データ駆動型設計」または「ドメイン駆動型設計」です。私はまだ OOP の初心者であり、あるオブジェクトが別のオブジェクトに含まれる理由を理解するのが難しいことがよくあります。ときどき、素晴らしいと思えるオブジェクトを見つけたときに、「よし、これをどこかに置かなければならないのだろうか?」と気付くことがあります。この背後にある理由は、ハードディスクにファイルを配置することを決定した場所と似ていますか?

これには、いくつかの指針があります。

  • 物理的な世界での関係をモデル化する場合。
  • コンポーザーがオブジェクトの構築に必要なデータを持っている場合。
  • 構成されたオブジェクトがコンポーザーをリッスンする場合。

この決定を下すとき、あなたは何を求めますか?

4

3 に答える 3

3

これを行うのに役立った非常に単純な概念の 1 つは、単純に「has a」と「is a」の概念です。含まれているオブジェクトは、含まれているオブジェクトが持っているものなのか、それとも含まれているオブジェクトそのものなのかを自問してください。それが包含オブジェクトにあるものである場合、包含は適切です。それ以外の場合は、継承を検討する必要があります。

犬は動物であり、鼻があるので、次のようになります。

class Animal
{
}

class Dog : Animal
{
    Nose n;
}

これで問題なく動作します。このアプローチの「問題」の 1 つは、鼻と犬を密接に結びつけることです。そのため、オブジェクトではなくインターフェイス ポインターが含まれている場合や、Google で「依存性注入」を検索する場合があります。しかし、ことわざにあるように、「has a」と「is a」は、政府の仕事にとって十分に近いことがよくあります。

早い段階で、たくさんの例を試してみてください。時間の経過とともに自然になります。スパゲッティになってしまったら、ミートボールを投げてやり直してください！:)

于 2009-08-30T03:59:08.323 に答える
0

ときどき、すごいオブジェクトを見つけて、「さて、これをどこかに置かなければならないのか」と気付くことがあります。

上記の文章から、あなたは下から上にデザインしようとしているように聞こえます。私が何年にもわたって学んだことの1つは、トップダウン設計が進むべき道であるということです。クラスは、使用する必要がある場所がわかった後でのみ作成する必要があります。そうしないと、「すごいように見える」クラスを作成してしまい、まったく役に立たない可能性のあるコードが含まれることになります。

于 2009-09-01T12:31:31.810 に答える
0

どのような代替案を検討していますか? 封じ込め対継承について話しているのですか? hasA と isA に関する John Lockwood のコメントは、その問題の解決に役立ちます。

それとも、封じ込め対関連付けについて話しているのでしょうか? hasA にはさまざまなフレーバーがあります。たとえば、人は配偶者を持っているかもしれませんが、明らかに配偶者を含んでいません。配偶者の変更と鼻の変更には違いがあります。

検討する関係の種類:

  • ライフタイム: 鼻のない人物を作成することは理にかなっていますか? ノーズは人がいなくても存在できますか? 人は配偶者なしで存在できますか? これらの質問に対する答えによって、Person に対して選択する操作の種類が決まります。おそらく setNose() メソッドは必要ありませんが、wipeNose() メソッドが必要な場合もあれば、mary(Person) メソッドが必要な場合もあります。

  • カーディナリティ: 人の鼻の数は? 車両にはいくつの車輪と座席がありますか? これに対する答えは、データ構造の種類を決定しますか? ただの参考？リスト？ハッシュテーブル？

UML モデリング、特にクラス図について読むと役に立ちました。これは、さまざまな種類の関係を有効に捉える方法に関する多くの経験を反映しています。

于 2009-08-30T20:07:48.697 に答える