問題タブ [composition]

構成の設計が委任とどのように異なるかなど、実装に関して何か違いはありますか。たとえば、以下のコードは委譲を行っているように見えます。これは、ユーザーが b を使用せずに構成されたオブジェクト (つまり "a") にアクセスできないためです。したがって、ユーザーはクラス b のインターフェースを呼び出してから、「クラス b」が「クラス a」の適切なインターフェースを呼び出して委任する必要があります。これは理にかなっていますか？

1) 家がなければ部屋は存在できず、家には「部屋がある」。(composition)
2) 部屋に色を付けるもう 1 つの方法は、House にメソッドを持ち、ColorRoom in Room メソッドを呼び出すことですが、これはより委任的です。（これを避けたい）

私が見る唯一の方法は上記のものですが、プライベートメンバーへの参照を返すことはOOPを壊しているようです。これは良いデザインですか？

WF(3.5)でワークフローの構成を作りたいと思っています。ワークフローを別のワークフロー内のアクティビティとして直接使用することはできますか? InvokeWorkFlowActivity はワークフローを非同期で実行するため、使用したくありません。

クラス Parameter があります。その目的は、特定のパラメーターが保持できる可能性のある値を表すことです (GetNumValues() と GetValue(int index) の 2 つの主要なメソッドを実装します)。

多くの場合、1 つの論理パラメーター (パラメーター値はビット フラグ) は、パラメーター クラスの 2 つ以上のインスタンス (つまり、1 または 2 のパラメーターと、4 または 8 のパラメーター) によって最適に表現されます。 5、6、9、または 10)。これを処理するには、パラメーターを含む CompositeParameter クラスを作成し、保持するパラメーターの組み合わせに基づいて GetNumValues() および GetValue() 関数を実装します。

また、CompositeParameter はパラメーターを組み合わせて 1 つのパラメーターとして機能させるため、「CompositeParameter はパラメーターである」という関係は理にかなっています。そのため、継承元のクラスのオブジェクトを構成するクラスがあるという状況に陥っていますが、これは正しくないようです。しかし同時に、より高いレベルのコードが CompositeParameters と Parameters をまったく同じに扱うことができない理由がわかりません。

私が考えることができる唯一のオプションは、CompositeParameter に単純にパラメーターを構成させることであり、より高いレベルのコードは CompositeParameters のみを処理します。ただし、これはやや無駄です。一般的なケースは、パラメーターを 1 つだけ含む CompositeParameters です。

考え？

Scalaで、私は構成を見てきました

と

同様のことを実現するために使用されます（つまりS、インスタンスを作成する前に、の抽象メソッドを定義する必要があります）。それらの違いは何ですか？なぜあなたは一方を他方の上に使うのですか？

構成と継承。

どちらも適切な場合に選択すべきツールであり、コンポジションと継承のどちらを選択するかはコンテキストが非常に重要であることを認識しています。ただし、それぞれの適切なコンテキストに関する議論は、通常、少しあいまいです。これにより、継承とポリモーフィズムが従来の OOP の別個の側面であることがいかに明確であるかを考え始めました。

ポリモーフィズムにより、「is-a」関係と継承を同等に指定できます。特に、基本クラスから継承すると、そのクラスとそのサブクラスの間に多態的な関係が暗黙的に作成されます。ただし、ポリモーフィズムは純粋なインターフェイスを使用して実装できますが、継承は実装の詳細を同時に転送することにより、ポリモーフィックな関係を複雑にします。このように、継承は純粋なポリモーフィズムとはまったく異なります。

ツールとしての継承は、些細なケースでの実装の再利用を簡素化することにより、(純粋なインターフェイスを介した) ポリモーフィズムとは異なる方法でプログラマーに役立ちます。. ただし、ほとんどの場合、スーパークラスの実装の詳細は、サブクラスの要件と微妙に競合します。これが、「オーバーライド」と「メンバーの非表示」がある理由です。これらの場合、継承によって提供される実装の再利用は、コードのカスケード レベル全体で状態の変更と実行パスを検証するという追加の労力によって購入されます。サブクラスの完全な「フラット化された」実装の詳細は、複数のクラスに分散されます。複数のファイル。その一部のみが問題のサブクラスに適用されます。スーパークラスのコードを見ないと、オーバーライドされていない詳細が状態を操作したり、実行を迂回させたりしていることを知る方法がないため、継承を扱うときは、その階層を調べることが絶対に必要です。

比較すると、コンポジションを排他的に使用すると、明示的にインスタンス化されたオブジェクトによってどの状態が変更され、そのメソッドが任意に呼び出されるかがわかります。真にフラット化された実装はまだ達成されていません (そして、構造化プログラミングの利点は実装の詳細のカプセル化と抽象化であるため、実際には望ましいことではありません) が、それでもコードを再利用することができ、1 か所を調べるだけで済みます。コードが正しく動作しない場合。

これらのアイデアを実際にテストすることを目標に、伝統的な継承を避けて、純粋なインターフェースベースのポリモーフィズムとオブジェクト構成の組み合わせを避けています。

継承では達成できないオブジェクトの構成とインターフェイスはありますか?

編集

これまでの回答で、ewernli は、一方の技術に利用できる技術的偉業はなく、他方の技術には利用できないと考えています。彼は後で、それぞれの手法に固有のパターンと設計アプローチの違いについて言及しています。これは理にかなっています。しかし、この提案により、従来の継承の代わりにコンポジションとインターフェイスを排他的に使用すると、主要なデザイン パターンの使用が禁止されるかどうかを尋ねることで、質問を絞り込むことができます。もしそうなら、私の状況で使用するための同等のパターンはありませんか?

各若いGCイベントの後、古い世代に昇格した若い世代のメモリの構成を決定する最良の方法を教えてください。

理想的には、「若い世代 -> 古い世代」の各プロモーション チャンクのヒープの 80% を担当するクラス名を知りたいです。

例: 私には 6 億人の若い世代がいて、在職期間ごとに 600 万人が昇進します。この 6M を構成するオブジェクトを知りたいです。

ありがとうございました。

classのいくつかの機能を使用するを持っているとしましょうdict。以前はオブジェクトを内部で合成dictし、外部からのアクセスを提供していましたが、最近、dict必要な属性とメソッドを単純に継承して追加することを考えました。それは良い方法ですか、それとも構成に固執する必要がありますか?

構成と継承は同じですか? 構成パターンを実装したい場合、Java でそれを行うにはどうすればよいですか?