問題タブ [composition]

私は ColdFusion プログラミングに慣れていないので、この質問は素朴かもしれません。

f1コンポーネント内に関数 を記述したタスクがあります。同じコンポーネントf1で定義された別の関数から呼び出したい。f2

f2cfm ファイルで呼び出されています。

私の質問 - これは正しい方法ですか? f1から呼び出すことはできますf2か?

にマージf1することもできますが、別の関数としてf2保持したいと思います。f1

集約と構成を使用してシミュレーション用のエンティティを作成しています。

次の C++ の例では:

上記の例では、車はエンジンと一連の運転制御装置 (構成による) で構成されています。車にはドライバーも必要です (集計による)。

しかし、これは階層関係を説明するだけです。ドライバーは車に属し、エンジンとコントロールも車に属します。しかし、これらのメンバーはすべて互いに関連しています。ドライバーはコントロールでアクションを実行する必要があり、コントロールはエンジンでアクションを実行する必要があります。これらの関係は複数の方向にも作用します。エンジンが失速してコントロールが動かなくなったり、コントロールが乱暴にスピンしてドライバーを傷つけたりする可能性があります。また、ドライバーがエンジン音が気に入らず、車から離れたらどうしますか? これらの関係はどのように機能しますか?

私は、他のオブジェクトと頻繁に相互作用する多くの異なるオブジェクトから多くの異なるエンティティを合成しており、これらの関係を設計された方法で管理する方法に興味があります。

ありがとう！

編集：

回答が示唆するように、これを管理する 1 つの方法は、車をドライバーに向けたり、ドライバーに車へのポインターを提供したりすることです。これは理にかなっていて、この特定の例を解決します。ただし、設計上の意味では、これはドライバーの責任を増大させます。このオブジェクトは、どの車に属しているかを追跡する役割を担っていますが、確かにこれは、どのオブジェクトが一緒に属しているかを追跡するコンテナの義務なのでしょうか? 同様に、これらの関係の管理を CCar に任せると、CCar がブロブになります。この種の関係に対処するための設計されたソリューションはありますか?

以下を機能させようとしていますが、途方に暮れています...

私がやりたいことは、クラス Foo 内に SomethingElse クラスのインスタンスを作成することです。これは を使用して機能し=&ます。しかし、クラス Foo をクラス Bar で拡張すると、子はすべてのデータ属性とメソッドを親クラスから継承すると思いました。ただし、$this->somethingelse子クラス Bar では機能しないようです。

では、そのように継承することはできないのでしょうか。また、Bar クラスで使用したい場合、SomethingElse クラスの新しいインスタンスを作成する必要がありますか? または、何か不足していますか？

よろしくお願いします。

時折、エンタープライズ アプリケーション アーキテクチャで継承が「時代遅れ」になっているというコメントに出くわすことがありますが、競合する理論を説明している記事へのリンクは見つけていません。また、ゼロから始めるのではなく、アプリケーションが既に構築されている場合、実装に違いはありますか? これは、代わりにインターフェイスに大きく依存していることと関係があるのではないかと考えていますが、よくわかりません。

私はMEFを実験していて、次のような特定のインターフェイスを実装する「プラグイン」を呼び出すテストプログラムを作成しました。

独自のアセンブリから、および見つかった場合は追加のDLLを配置するディレクトリから「プラグイン」をロードするサンプルコンソールプログラムを作成しました。プラグインディレクトリが空であるか（「ネイティブ」プラグインのみが呼び出される）、または互換性のあるDLLがあるかどうかに関係なく、プログラムは正常に動作します。しかし...ループの反復の間に新しいDLLが追加されると、DirectoryCatalogのRefresh（）メソッドはChangeRejectedExceptionをスローします。これは、次のように説明されます。

構成は変更されません。次のエラーのため、変更は拒否されました。コンポジションで単一のコンポジションエラーが発生しました。根本的な原因を以下に示します。詳細については、CompositionException.Errorsプロパティを確認してください。

1）パーツ「MEFTest.Program」の再構成不可能なインポート「MEFTest.Program.ProberSet（ContractName = "ProbeContract.IProbe"）」によって防止されたエクスポートの変更。

プログラムは以下のとおりです。追加しようとしているDLLのコードが続きます。私は何が間違っているのですか？

プラグイン。他の2つのプラグインは類似していますが、唯一の違いは、メインプログラムと同じアセンブリに存在することです。

大規模なプロジェクトでユーザー インターフェイスを合成および集約するための WPF のベスト プラクティスに関するドキュメントを探しています。

私は、Delphi と Winform を使用して視覚的な継承の世界から来ています。そして今、私はそのようなパターンをうまく再現しようとしています.

私は提案と読書にオープンです。

私は最近、私が書いたさまざまなSWコンポーネントの詳細なUML設計を実行するのにかなりの時間を費やしました。私が最近終えたことを振り返り、それを最初にUMLを学んだときと比較すると、今ではほぼ厳密に集約と構成の関係を使用し、「バニラ」の無向/有向の関係を事実上放棄していることがわかります。もちろん、私はまだ一般化と実現を使用していますが、これらは上記のものとは明らかに異なり、この質問の一部とは見なされません。

アグリゲーション/コンポジションは、「バニラ」アソシエーションなどと同じ意味を持っているように私には思えます。アグリゲーションとコンポジションは当然方向性を意味します。最新のUMLプログラムでは、アグリゲーション/コンポジションの関係に多重度を定義し、その関係に動詞を適用することもできます。その時点で、私はバニラ協会にほとんど目的を見ていません。

アグリゲーションとコンポジションの違いを理解するのが難しい人もいると思います。早い段階で、それらがどのように異なるかを理解するのは少し困難でした。混乱がバニラアソシエーションを使用した理由の一部だったと思います。私は今、バニラアソシエーションの使用がほとんどまたはまったく見られず、実際には、バニラアソシエーションがいくつかの問題（特に2つのオブジェクト間の強いまたは弱いライフサイクル関係）を残していると信じているため、それらが使用されるのを見るのが嫌いです。バニラアソシエーションの唯一の実用的な用途は、目前の問題についての理解がまだ十分に発達しておらず、集約と構成のライフサイクルの違いを判断できない場合だと思います。そのような場合は、少なくともショーをする方が良いです関係が存在し、目前の問題をよりよく理解したときに、戻って適切に変更できること。

簡単に言えば、人々がバニラアソシエーションを使用する時間の大部分は、より正確には集合体として、場合によっては構成として説明できると思います。私は自分の信念がひどく間違っていますか？私は何かが足りないのですか？聞かせて！

言語構文は無視してください。ここでは OOPS についてのみ説明します。

ここに 2 つのコード スニペットを示します。それぞれがコンポジションのサンプルです (私が間違っていなければ)。

問題文: システム内のエンティティの統計を保持するオブジェクトがあります。それらの統計を次のようにします。

1. 名前
2. 苗字
3. 給料

*これらのフィールドは何でもかまいません。私はこれらを例に取りました。どの分野が必要かどうかという観点から考えないでください。3 つすべてが必要であると仮定します。

これらのフィールドに対応するクラスを作成しました:

今、私はある人についての情報を時系列で知りたいという状況に遭遇しました。ワークフロー システムのある時点で、3 つのステージすべてについて個人に関する情報を提示する必要があることを見てみましょう。

1. 彼が子供だったとき。
2. 彼が若かったとき。
3. 彼が退職したとき。

ここで注意すべき点は、nameとlastNameは変わらず、給与のみが変わる可能性があるということです。このため、既存のオブジェクト「stats」を使用できるクラスを作成できるのではないかと考えました。

2 つの解決策を紹介します。どちらが優れているか、またその理由を教えてください。

コード例 1

上記のサンプル コードでは、給与の元のフィールドを公開しませんでしたが、期間ごとに 3 つの新しいフィールドを作成しました。

コード例 2

Web サービス構成とは正確には何ですか?