問題タブ [composition]

なぜ継承よりも構成を好むのですか？各アプローチにはどのようなトレードオフがありますか？いつ、構成よりも継承を選択する必要がありますか？

私は軽量のゲーム エンジンを作成しており、そのための調査を行っているときに、「具象クラスからの継承」モデルではなく「コンポーネントのコレクション」モデルによるゲーム オブジェクトの実装を提唱する説得力のある記事をいくつか見つけました。多くの利点があります:

• オブジェクトは、データ駆動型の設計手法を使用して構成できるため、設計者はプログラマーを関与させずに新しいオブジェクトを考え出すことができます。
• ソースファイルの依存関係が少なくなる傾向があるため、コードをより高速にコンパイルできます。
• エンジン全体がより一般的になります。
• 継承階層の上位にある具体的なクラスを変更しなければならないという予期しない結果を回避できます。
• 等々。

しかし、システムには不透明な部分があります。主に、同じオブジェクトのコンポーネントが相互に通信する方法です。たとえば、ゲーム内の弾丸をモデル化するオブジェクトが、次のコンポーネントに関して実装されているとします。

• 視覚的表現のためのジオメトリのビット
• 世界での地位
• 他のオブジェクトとの衝突に使用されるボリューム
• 他のもの

レンダリング時に、正しく表示するためにジオメトリはワールド内での位置を認識している必要がありますが、オブジェクト内のすべての兄弟コンポーネント間でその位置をどのように見つけるのでしょうか? また、更新時に、他のオブジェクトとの交差をテストするために、コリジョン ボリュームはどのようにしてワールド内のオブジェクトの位置を見つけるのでしょうか?

私の質問は次のように要約できると思います: さて、それぞれが少しの機能を実装する多数のコンポーネントで構成されるオブジェクトがあります。これが実行時に機能するための最良の方法は何ですか?

単純なオブジェクト指向設計の問題にどのようにアプローチするかについて質問したいと思います。このシナリオに取り組む最善の方法について、私自身の考えがいくつかありますが、スタック オーバーフロー コミュニティから意見を聞くことに興味があります。関連するオンライン記事へのリンクも歓迎します。私は C# を使用していますが、質問は言語固有ではありません。

、、フィールドPersonを持つテーブルを持つデータベースのビデオ ストア アプリケーションを作成しているとします。また、 へのリンクを持つテーブルと、にもリンクするテーブルもあります。PersonIdNameDateOfBirthAddressStaffPersonIdCustomerPersonId

Customer単純なオブジェクト指向のアプローチは、a が"is a"であると言って、次のPersonようなクラスを作成することです。

これで、すべての顧客にメールを送信する関数を作成できます。

このシステムは、顧客とスタッフの両方である誰かがいるまでは問題なく機能します。everyoneリストに同じ人物が 2 回 (1 回は a として、1 回は a として)Customer含まれることを本当に望んでいないと仮定すると、次Staffのいずれかを任意に選択しますか?

と

明らかに、これら 2 つのうち最初のものだけがSendEmailToCustomers機能を壊すことはありません。

それで、あなたは何をしますか？

• クラスにおよびクラスPersonへのオプションの参照を持たせますか?StaffDetailsCustomerDetails
• Personに加えてオプションStaffDetailsとCustomerDetails?を含む新しいクラスを作成します。
• すべてをインターフェイス (例: IPerson、IStaff、ICustomer) にして、適切なインターフェイスを実装する 3 つのクラスを作成しますか?
• 別のまったく異なるアプローチをとりますか？

数週間前、私のピアノの先生と私は、メタ作曲音楽ソフトウェアについて互いに意見を交換していました。アイデアはこれでした：

たくさんの楽器から MIDI 入力を受け取り、出力をスピーカーとライトにプッシュするシステムがあります。このシステムで実行されているソフトウェアは、取得した MIDI データを分析し、作曲者が設定したトリガーに基づいて、使用するサウンドを決定します (F7 コードを 2 秒以内に 3 回演奏すると、ハープシコードのサウンドからピアノのサウンドに切り替わります)。 )、ペダル、または音楽の実際のリアルタイム分析。同様の方法で、楽器のパフォーマンスとサウンドに基づいてライトを制御します。ミュージシャンは、希望するものを漠然と指定するだけで済みます。残りは、演奏のリアルタイム分析によって行われます。その場で手続き的に生成された音楽は、ミュージシャンと一緒に演奏することもできます。基本的に、ソフトウェアはパフォーマーと一緒に演奏し、一方が他方をガイドします。

私は即興ジャズの大ファンです。他の芸術形式に欠けている即興の特徴の 1 つは、その一時性です。絵画は描かれてから 10 年後、1000 年後に鑑賞することができますが、音楽 (特に即興音楽) は創作物であるためパフォーマンスが重要です。私が説明したソフトウェアは、まったく同じ曲を演奏すると毎回まったく異なるショーになるため、それと同様に、パフォーマンスに多大な追加をもたらすと思います.

それでは、質問です。

私はクレイジーですか？

これらの一部またはすべてを実行するソフトウェアはまだ存在しますか? 私はいくつかの調査を行いましたが、何も見つかりませんでした。このシステムの鍵は、パフォーマンス中に実行されることです。

私がこのようなものを書いたとしたら、Python などのスクリプト言語は、私が必要とする計算を実行するのに十分高速でしょうか? おそらく、かなり高速なシステムで実行され、Intel がリリースし続けている 2^n コア プロセッサを利用することができます。

楽器やライトなどとのインターフェースに関する経験やアドバイスを教えてください。

アイデアや提案はありますか？冷酷で厳しい批判？

これを読んでくれてありがとう、そしてあらゆるアドバイスをありがとう！（そして、タグの冗談で申し訳ありません、私は抵抗できませんでした。）

まず第一に、私は言語理論についてほとんど何も知りませんし、Java 以外の他の言語はほとんど知りませんが、私はクールだと思うアイデアを持っていまし
た
.言語 x が何年もの間それを持っていた
方法 c: 頭がおかしい
d: 上記のすべて

このアイデアは、構成にコードの再利用を同じように容易にextendsします。

したがって、次のようなクラスがあるとします。

そして、次のようなクラスがありました：

その後、これを行うことができます：

B のクラスに委任を追加する必要はありません。ただし、継承と同じこともできます。つまり、次のようになります。

欠点は次のとおりです。

• メソッドはソース コードに隠されているため、呼び出し元がわかりにくくなっていますが、これは次の場合にも当てはまります。extends
• 構成されたフィールドが同じメソッド シグネチャを共有する場合、競合を解決する必要があります (競合するインターフェイスはこれをどのように解決しますか?)
• 同じタイプの複数の合成フィールドが必要な場合は、どのフィールドに委譲するかについて明らかな競合が発生します。
• おそらく私が考えたことのない他の100のこと

私が言うように、私は明らかに言語理論家ではありませんし、それについて何年も考えたこともありません。アイデアが頭に浮かんだだけで、自分がどれほど間違っているかを知りたいと思いました. ちょっとクールだと思います。

ポートフォリオA → ファンド1

ポートフォリオA → ファンド2

ポートフォリオA → ファンド3

is/has を使わずに文章を構成することはできませんでした。しかし、1と2の間では、

1) 次のものがあります。

2) は:

拡張性、使い勝手の点でどちらが優れていると思いますか？多少の構文変更はありますが、どちらの方法でも資金にアクセスできます。

簡単な例のコンテキストで質問をしようと思います...

抽象基本クラス Car があるとします。車には基本的なエンジン オブジェクトがあります。エンジンの始動を Engine オブジェクトに委譲する抽象 Car クラスに StartEngine() メソッドがあります。

Car のサブクラス (Ferrari など) が Engine オブジェクトを特定のタイプのエンジン (TurboEngine など) として宣言できるようにするにはどうすればよいですか? 別の Car クラス (TurboCar) が必要ですか?

単純な古い Engine オブジェクトを継承していますが、Car サブクラスでそれを TurboEngine として再宣言 (またはオーバーライド) することはできません。

編集: Engine の任意のサブクラスを Ferrari クラス内の myEngine 参照にプラグインできることは理解していますが、TurboEngine のみが公開するメソッドを呼び出すにはどうすればよいですか? myEngine はベース エンジンとして継承されるため、ターボ関連のものは含まれません。

ありがとう！

私はこのようなことを達成しようとしています:

foo が初期化される前に派生コンストラクターで bar() が呼び出されるため、これは私が望むようには機能しません。

foo をパラメーターとして取る bar() に似た静的関数を追加することを検討しました-そしてそれを初期化リストで使用しましたが、これを掘り下げるために使用できる他の手法があるかどうか尋ねたいと思いました。 ..

編集: フィードバックをお寄せいただきありがとうございます。ここでは、静的関数を処理する方法を示します。静的関数と非静的関数の間のオーバーロードが巧妙すぎるかどうかはわかりませんが...

次のようなタイプの関数がある場合

この関数をnotでラップするmake関数が欲しいです。

たとえば、このような関数を作る

コンビネータを次のように作成できます

しかし、方法がわかりません。

私は何を間違っていますか？

そして、ボーナスの質問は、より多くのパラメーターと最も少ないパラメーターを使用して関数に対してこれを行う方法です。

ASP.NET MVC ビューで外部のコンポーザブル パーツをサポートするにはどうすればよいでしょうか?

これはどういう意味ですか？「すべてのページのログイン ボックス」または「iGoogle」のいずれかを考えてください。各コントローラー/ビューの外部にある特定の場所にある必要があるものです。

これに対する 1 つのアプローチは、次のようにビューにコンポーネントを追加することです。

上記の例では、表示されるビューのコントローラーではなく、各コンポーネントのコントローラーによってビュー名とビューデータを配信する良い方法を探しています。あなたが提案できるまったく異なる解決策も興味深いでしょう。フィルター、Web フォームなど。

更新:例を使用して、頭を包み込もうとしていることを説明しようと思います。ログイン機能を選択します。

典型的な Web フォーム アプリケーションでは、これは、ページのライフ サイクルのロード イベントで適切なデータを取得し、いくつかの UI コントロールを更新するユーザー コントロールである可能性があります。クリックすると、ページがポストバックされ、同じユーザー コントロールのクリック イベントでポストされた情報に基づいて行動できます。

ASP.NET MVC スタイルに関する私の現在の理解では、最初に要求を受け入れるコントローラーが適切なデータを取得し、それをビューに渡します。ビューはそれをログイン部分ビューに渡します。ログインビューは、投稿アクションがログインコントローラーのログインアクションに向けられるフォームを定義します。投稿された情報はlogin アクションによって使用され、気の利いたスキームを使用して元のコントローラーにリクエストを渡すことを選択できます。

ビュー/マスターページにコントローラーロジックを配置する必要のない、上記よりもスマートなアプローチがあると思います。