タグ付けされた質問 「composition」

過去数か月で、「継承よりも好意的な構成」というマントラがどこからともなく生まれ、プログラミングコミュニティ内でほぼ何らかのミームになったようです。そして、それを見るたびに、私は少し神秘的になります。誰かが「ハンマーよりもドリルを好む」と言ったようです。私の経験では、構成と継承は異なるユースケースを持つ2つの異なるツールであり、それらを互換性があり、一方が本質的に他方より優れているかのように扱うことは意味がありません。 また、なぜ継承が悪く、構成が良いのかについての本当の説明は見ていません。信仰によって受け入れられるだけなのでしょうか？リスコフ置換とポリモーフィズムには、明確で明確な利点があり、IMOはオブジェクト指向プログラミングを使用するすべてのポイントを構成します。構成を優先して破棄する理由を説明する人はいません。 この概念がどこから来たのか、そしてその背後にある理論的根拠は誰か知っていますか？

143 object-oriented  inheritance  composition 

私は常に、構成が継承よりも優先されることを読みました。種類とは異なり、上のブログの記事は、例えば、相続上の組成物を用いて提唱したが、私は多型が達成されたかを確認することはできません。 しかし、私は人々が作曲を好むと言うとき、彼らは本当に作曲とインターフェース実装の組み合わせを好むことを意味すると感じています。継承なしでどのようにポリモーフィズムを取得するのですか？ 継承を使用する具体的な例を次に示します。構成を使用するためにこれをどのように変更しますか？ Class Shape { string name; public: void getName(); virtual void draw()=0; } Class Circle: public Shape { void draw(/*draw circle*/); }

109 interfaces  inheritance  composition 

たとえば、他のクラスを拡張するクラスがあるとします。 public class LoginPage { public String userId; public String session; public boolean checkSessionValid() { } } およびいくつかのサブクラス： public class HomePage extends LoginPage { } public class EditInfoPage extends LoginPage { } 実際、サブクラスにはオーバーライドするメソッドがありません。また、一般的な方法でHomePageにアクセスしません。つまり、次のようなことはしません。 for (int i = 0; i < loginPages.length; i++) { loginPages[i].doSomething(); } ログインページを再利用したいだけです。ただし、https: //stackoverflow.com/a/53354によると、インターフェイスLoginPageは必要ないため、ここでは構成を優先する必要があります。したがって、ここでは継承を使用しません。 public class HomePage …

36 inheritance  composition  dry 

から：http : //www.artima.com/lejava/articles/designprinciples4.html エーリッヒガンマ：10年経った今でも、それは真実だと思います。継承は、動作を変更するクールな方法です。しかし、サブクラスは、オーバーライドするメソッドが呼び出されるコンテキストについて簡単に推測できるため、脆弱であることがわかっています。私がプラグインするサブクラスコードが呼び出される暗黙的なコンテキストのため、基本クラスとサブクラスの間には密接な結合があります。構成には、より良い特性があります。結合は、いくつかの小さなものをより大きな何かにプラグインするだけで減少し、大きなオブジェクトは小さなオブジェクトをコールバックします。APIの観点から、メソッドをオーバーライドできることを定義することは、メソッドを呼び出すことができることを定義することよりも強力です。 私は彼が何を意味するのか理解していません。誰か説明していただけますか？

36 object-oriented  api  inheritance  composition 

多くのテキスト、特に関数型プログラミングテキストは、特定のCSの概念が「構成しない」と主張しています。例は次のとおりです。ロックは作成されません、モナドは作成されません。 私はこのフレーズの意味を正確に追跡するのに苦労してきました。構成について考えるとき、関数構成またはオブジェクト集約のいずれか（「継承よりも優先する構成」など）を考えますが、それはここで人々が使用している意味ではないようです。 上記の2つの例（つまり、ロックとモナド）のような式で使用される場合、誰かがこのフレーズの意味を説明できますか？

35 terminology  functional-programming  computer-science  composition 

このページは、次の引数を使用して継承よりも構成を推奨しています（私の言葉で言い換えます）。 サブクラスでオーバーライドされていないスーパークラスのメソッドのシグネチャの変更により、継承を使用するときに多くの場所で追加の変更が発生します。ただし、Compositionを使用する場合、必要な追加の変更は1つの場所であるサブクラスのみです。 それが本当に継承よりも構成を優先する唯一の理由ですか？その場合、サブクラスが実装を変更しない（つまり、サブクラスにダミーのオーバーライドを設定する）場合でも、スーパークラスのすべてのメソッドをオーバーライドすることを推奨するコーディングスタイルを適用することで、この問題を簡単に軽減できるためです。ここに何かが足りませんか？

13 object-oriented  inheritance  composition 

共通の基本型の別のクラスをラップするクラスがあります。基本型インターフェースは非常に大きいため、これには多くのパススルー関数の作成が含まれます。これを回避する方法を探しています。 例を作りましょう： Car / \ Volvo VolvoWithTrailer ここで、VolvoWithTrailerの車のインターフェイスにすべての関数を実装し、ラップされたVolvoオブジェクトで適切な関数を呼び出す必要があります。ただし、GetMaxSpeed（）は、より低い値を返します。基本的に次のような多くの機能があります int VolvoWithTrailer::GetNumSeats() { return mVolvo.GetNumSeats() } これを解決する明白な方法は、VolvoWithTrailerをVolvoのサブクラスにすることです。 Car | Volvo | VolvoWithTrailer しかし、それは継承よりも構成を優先するという原則に違反しているようです。 これらのすべてのラッパー（言語はC ++）を書くことを他にどのように回避できますか？または-それがあなたの立場である場合-なぜ私はそれらを書くだけですか/単に継承を使用するのですか？これに役立つテンプレートの魔法はありますか？

13 c++  inheritance  templates  composition 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 メモリの割り当て方法やメモリ管理（たとえばCから学べること）だけでなく、ハードウェアの側面や、コンピューターハードウェアの各コンポーネントが内部でどのように機能し、どのように相互に通信するかについても話します。 あなたはこれをすべて知っていますか？

13 composition 

私は自分自身にソフトウェア工学を教えようとしていますが、私を混乱させる矛盾する情報に出くわします。 私はOOPと抽象クラス/インターフェースとは何か、そしてそれらをどのように使用するかを学びましたが、「継承よりも合成を優先する」べきだと読んでいます。構成とは、あるクラスが別のクラスのオブジェクトを構成/作成して、その新しいオブジェクトの機能を利用/対話することです。 だから私の質問は...抽象クラスとインターフェイスを使用しないはずですか？抽象クラスを作成せず、その抽象クラスの機能を具象クラスで拡張/継承し、代わりに、新しいオブジェクトを作成して他のクラスの機能を使用するだけですか？ または、構成を使用し、抽象クラスから継承することになっています。両方を一緒に使用しますか？もしそうなら、それがどのように機能し、その利点のいくつかの例を提供できますか？ 私はPHPに最も慣れているので、他の言語に移り、新しく習得したSEスキルを移転する前に、それを使用してOOP / SEスキルを向上させています。

13 object-oriented  php  interfaces  inheritance  composition 

まず、私は初心者レベルのプログラマーです。実際、私は夏の最後の絶頂プロジェクトでASの学位を取得しています。私の新しい仕事では、私がやるべきプロジェクトがないとき（彼らはチームにさらに新しい採用をするのを待っています）、私は待っている間に読んで学ぶための本を与えられました-いくつかの教科書、他のそれほど多くはありません（コード完了など）。これらの本を読んだ後、できる限り多くのことを学ぶためにインターネットに目を向け、SOLIDとDIについて学び始めました（Liskovの代替原理についてはいくらか話しましたが、SOLIDのアイデアについてはあまり話しませんでした）。それで、私が学んだように、私はよりよく学ぶために座って、DIを手動で利用するためのコードを書き始めました（開発コンピューターにはDIフレームワークはありません）。 私がやっているように、それは馴染みのあることに気づきます...そして、ポリモーフィズムを使った抽象クラスの構成を使って過去にやった仕事に非常に似ているようです。ここに大きな画像がありませんか？DIについて（少なくとも手で）それを超える何かがありますか？再コンパイルすることなく物事を変更する限り、いくつかの大きな利点を持つDIフレームワークのコードに設定がない可能性を理解していますが、手動で行う場合、上記と異なるかどうかはわかりません...これに関するいくつかの洞察は非常に役立つでしょう！

13 dependency-injection  abstraction  polymorphism  composition 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 5年前に閉鎖されました。 より少ないから指数関数的に C ++とJavaが型の階層と型の分類に関するものである場合、Goは合成に関するものです。

12 programming-languages  go  composition 

インターフェイスを考えてみましょう： interface IWaveGenerator { SoundWave GenerateWave(double frequency, double lengthInSeconds); } このインターフェイスは、さまざまな形状の波を生成するいくつかのクラス（SineWaveGeneratorおよびなどSquareWaveGenerator）によって実装されます。 SoundWave生のサウンドデータではなく、音楽データに基づいてを生成するクラスを実装したいと思います。それは音の名前と拍数（秒ではない）の長さを受け取り、内部的にIWaveGenerator機能を使用してSoundWaveそれを作成します。 質問は、「をNoteGenerator含むIWaveGeneratorべきIWaveGeneratorですか、それとも実装から継承すべきですか？」 次の2つの理由から、作曲に傾倒しています。 1- 動的に任意のIWaveGeneratorものを注入できNoteGeneratorます。またNoteGenerator、、などSineNoteGeneratorでSquareNoteGeneratorはなく、1つのクラスのみが必要です。 2-でNoteGenerator定義された下位レベルのインターフェースを公開する必要はありませんIWaveGenerator。 しかし、私はこれに関する他の意見を聞くためにこの質問を投稿しています。おそらく考えていない点です。 ところで：私はそれがsを生成するため、概念的に言うNoteGenerator と思います。IWaveGeneratorSoundWave

11 object-oriented  object-oriented-design  inheritance  composition 

が、Javaのドキュメントを指定し、その弱参照は、主にマッピングをcanonicalizingために、あなたが見つけるされている多くの、多くの、多くのWeakHashMapは、その存続期間中にオブジェクト・メタデータを格納するための完璧であることを、述べてインターネット上の人々を。ただし、誰もがわかりやすく適切な例を作成することに煩わされることはありません。 WeakHashMapを使用してオブジェクトにいくつかのプロパティを追加するか、メタデータサウンドを格納します。言い換えれば、悪いデザインです。継承が利用できない場合があることを理解しています（最終的なクラス、インターフェース）が、構成についてはどうですか？合成が選択肢にならない一例は考えられません。「言語の癖」ではなく、確立された原則に依存しているので、確かにより良いものです。 それでは、単純な構成の代わりに弱参照を使用した方がよい状況はありますか？そうでない場合、なぜインターネット上の誰もがそれを誤解しているように見えるのですか？

10 java  inheritance  composition  metadata 

：私はクラスの持っているA、小さなクラスの数の複合体であるB、CとD。 B、C、およびDインターフェースを実装IB、ICおよびIDそれぞれ。 以来Aのすべての機能をサポートB、CおよびD、A実装IB、ICおよびID同様に、しかし、多くのこの残念ながらリードの実装で再ルーティングA そのようです： interface IB { int Foo {get;} } public class B : IB { public int Foo {get {return 5;}} } interface IC { void Bar(); } public class C : IC { public void Bar() { } } interface ID { string Bash{get; set;} } public …

10 c#  design-patterns  patterns-and-practices  composition 

このstackexchangeを簡単に検索すると、一般的に構成は継承よりも柔軟であると一般に考えられていますが、常にプロジェクトなどに依存し、継承の方が適している場合があります。3Dチェスゲームを作りたいのですが、各ピースにはメッシュがあり、場合によっては異なるアニメーションなどがあります。この具体的な例では、両方のアプローチのケースが間違っていると主張できるように思われますか？ 継承は次のようになります（適切なコンストラクターなどを使用） class BasePiece { virtual Squares GetValidMoveSquares() = 0; Mesh* mesh; // Other fields } class Pawn : public BasePiece { Squares GetValidMoveSquares() override; } これは確かに「is-a」の原則に従いますが、構成は次のようになります。 class MovementComponent { virtual Squares GetValidMoveSquares() = 0; } class PawnMovementComponent { Squares GetValidMoveSquares() override; } enum class Type { PAWN, BISHOP, //etc …

9 c++  inheritance  composition