問題タブ [composition]

1. MEF を使用して、DLL を作成します

2. 私は自分のDLLで作業しています

3. このDLLなしで再構成します

4. 削除したい // => うまくいかない

この dll が構成されていない MEF 再構成の後に、dll をアンロードして削除するにはどうすればよいですか?

既存の .NET アプリケーションのプラグイン解決のソリューションとして MEF を研究しています。

私が見つけたすべての例で、メイン アプリケーションは CompositionContainer のインスタンスを作成し、container.ComposeParts(this) を呼び出します。

問題は、私のアプリケーションが完全に MEF で構築されているわけではないため、オブジェクト グラフに MEF コンポーネントのない穴が開いていることです。したがって、私のオブジェクト階層は次のようになります。

アプリケーション (MEF コンテナー) -> ObjectB (MEF なし) -> ObjectA (MEF インポートが必要)

このオブジェクト階層では、アプリケーションで container.ComposeParts(this) を呼び出して、アプリケーションが ObjectB を作成し、ObjectA のインポートを満たすことを期待することはできません。

アプリケーションの起動時よりも後で ObjectA を作成できるように、CompositionContainer をグローバルに公開することは良い方法ですか?それとも、線形 MEF オブジェクト グラフをサポートするためにアプリケーション全体を再構築する必要がありますか?

継承と構成の次の違いを抽出しました。バックエンド オブジェクトの作成の遅延とはどういう意味ですか? 以下の違いを見つけてください。

コンポジションを使用すると、バックエンド オブジェクトが必要になるまで (およびそうでない場合)、バックエンド オブジェクトの作成を遅らせたり、フロントエンド オブジェクトの存続期間全体にわたってバックエンド オブジェクトを動的に変更したりできます。継承を使用すると、サブクラスが作成されるとすぐにサブクラス オブジェクト イメージ内のスーパークラスのイメージを取得し、サブクラスの存続期間を通じてサブクラス オブジェクトの一部として残ります。

コードをクラスに分割しようとしています。しかし、本当に私を悩ませている問題があります。関数のクラスを作成すると、独自のステージが与えられます。このような

クラスではこれを使用します

ご覧のとおり、stage.var1 = "hi" を使用してステージの変数を呼び出すことができるようになりましたが、その変数を何度も調整する必要があると、かなり面倒になります...

私が var1 を呼び出すと、stage を呼び出す必要なく、stage.var1 を意味することを彼が知っていることを伝える方法があります。これは：

そして使用する

しかし、それも非常に不便です。より良い方法はありますか？

私は、vb.netプログラミングの経験のかなり早い段階で、実際に作成する必要のある別のクラスから継承したクラスを作成しました。基本クラスは、比較的一般的なネストされた辞書ベースのコレクションです。子孫クラスを「車」と呼びましょう。

現在、「MyCar！Color.st = "Red"」のようなことを行うコードがたくさんあります（VB6で記述されたコードとのデータ交換を容易にし、車の比較を容易にするために、実際のプロパティではなく汎用コレクションを使用します。 3台の車X、Y、Zが与えられた場合、たとえばXとYの間の変更を検出し、それらの変更をZに適用できます。

継承ではなく構成を使用するようにコードをリファクタリングする良い方法はありますか？「Car」オブジェクトはどのプロパティ/メソッドをラップする必要があり、どのプロパティ/メソッドにデータオブジェクトプロパティを介してアクセスする必要がありますか？車とコレクションオブジェクトの間で拡大変換を定義する必要がありますか？このようなリファクタリングを行う際の落とし穴はありますか？

たとえば、次の要件がある場合: 1. 犬は動物 2. 動物園には動物がいます。

質問は以前に議論されたことがあることを私は知っていますが、それは常に継承が少なくとも時々作曲よりも好ましいという仮定の下にあるようです。ある程度の理解を得るために、その仮定に挑戦したいと思います。

私の質問はこれです：古典的な継承でできるオブジェクトコンポジションで何でも達成でき、古典的な継承は非常に頻繁に悪用されるため[1] 、オブジェクトコンポジションはデリゲートオブジェクトの実行時間を変更する柔軟性を提供するので、なぜこれを使用するのでしょうか古典的な継承？

委任に便利な構文を提供しないJavaやC++などの一部の言語で継承を推奨する理由は理解できます。これらの言語では、明らかに正しくない場合はいつでも、継承を使用することで多くの入力を節約できます。しかし、Objective CやRubyのような他の言語は、古典的な継承と委任のための非常に便利な構文の両方を提供します。Goプログラミング言語は、私の知る限り、古典的な継承は価値があるよりも厄介であり、コードの再利用のための委任のみをサポートすると判断した唯一の言語です。

私の質問を述べる別の方法はこれです：古典的な継承が特定のモデルを実装するのに正しくないことを知っているとしても、その理由は構成の代わりにそれを使用するのに十分ですか？

[1]多くの人は、クラスにインターフェースを実装させる代わりに、古典的な継承を使用してポリモーフィズムを実現します。継承の目的は、ポリモーフィズムではなく、コードの再利用です。さらに、継承を使用して、問題となることが多い「is-a」関係の直感的な理解をモデル化する人もいます。

アップデート

継承について話すとき、私が正確に何を意味するのかを明確にしたいだけです。

私は、クラスが部分的または完全に実装された基本クラスから継承する種類の継承について話しています。私は、インターフェイスを実装するのと同じことになる純粋に抽象的な基本クラスから継承することについて話しているのではありません。

アップデート2

継承がポリモーフィズムiC++を実現する唯一の方法であることを理解しています。その場合、なぜそれを使用しなければならないのかは明らかです。したがって、私の質問は、ポリモーフィズムを実現するための明確な方法（それぞれ、インターフェースとダックタイピング）を提供するJavaやRubyなどの言語に限定されています。

Windows の Aero テーマ グラス機能に対する Delphi 2009/2010 のサポート、正確には DoubleBuffered の意味、および Aero グラスとの関係について混乱しています。DoubleBuffered は VCL のプロパティであるだけでなく、 .net WinFormsにもあることがわかりました。最初は、コモン コントロール ライブラリで使用されるある種のウィンドウ スタイル ビットが設定されているのではないかと考えていました。なぜ使用するのか、いつ使用する必要があるのか​​?

[更新: ちらつきを軽減するための一般的な手法として、「ダブル バッファリング」とは何かを知っていることを述べる必要があります。 Windows 7. 以下にリンクされているブログ投稿が最も有益なようです。]

特に、DoubleBuffered プロパティに混乱しています。なぜそれが存在するのか、フォームとコントロールのガラス サポートとダブル バッファリングされたプロパティの間の関係がどのように設定されているのかを知りたいです。このような C++ の記事を読むと、ダブル バッファリングについて言及されていないことがわかります。

【追記２：以下、一部事実誤認があり訂正しました】

従来の Win32 アプリで DWM/Aero 合成をオンにしたときに、DWM/Aero 合成が引き起こす「黒がガラスになる」グリッチを回避するために、SetLayeredWindowAttributes を呼び出す方法について話している C++ 開発者を見つけました [ただし、以下のブログ リンクは、これが機能しなくなったことを示しています。 Windows 7 で、Microsoft がブロックするまで、実際には Vista で短時間しか機能しませんでした]。[間違った考えを始める]明るいマゼンタのような他の色を使用して、それをガラスの透明色に変えるべきではありませんか? [間違った考えを終わらせる]

DoubleBuffered を設定する必要がある場合と設定しない場合のルールは何ですか? そもそも DoubleBuffered が VCL に追加されたのはなぜですか? 設定するといつ問題が発生しますか？(リモート デスクトップが 1 つのケースのようですが、それが唯一のケースですか?) そして、それが設定されていない場合、ボタン テキストのレンダリングに問題が発生します。これは、Delphi がデフォルトの「ガラスとして黒をレンダリングする」を変更していないように見えるためです。 " Aero DWM で。

Aero グラスのレンダリングは基本的に奇妙で理解しにくい方法で行われているようです [この機能をラップするだけの Delphi ではなく、Windows 自体によって]、2009/2010 の内部 VCL ソース コードの多くStdCtrls のクラスは、Aero Glass で正しくレンダリングするために多くの複雑なロジックを実行する必要がありますが、まだ多くの問題があり、間違っているように見えます。 [更新 3: ガラスの多くのレンダリング グリッチ、VCL では、一般的なコントロール内で間違ってレンダリングされているようですが、Microsoft は修正を気にしていないようです。要するに、Delphi VCL コードの修正では、古い Windows 共通コントロール ライブラリと最新の [しかし風変わりな] Aero Glass 合成機能が互いにあまり好きではなく、特にうまく連携しないという事実を修正することはできません。このような高品質のテクノロジを構築し、それを世界に広めてくれた Microsoft に感謝します。]

そして、まだ十分に楽しくない場合。ParentDoubleBuffered があるのはなぜですか?

[7 月 30 日の更新: この質問は私にとって興味深いものです。なぜなら、大規模な既存の VCL フレームワークがある場合、この問題を解決するために Windows API に取り組むことは困難な問題であることを示していると思うからです。]

Java の世界 (より正確には、複数の継承/ミックスインがない場合) の経験則は非常に単純です: 「クラスの継承よりもオブジェクトの構成を優先する」。

特にscalaで、ミックスインも検討する場合、それがどのように変更されるかを知りたいですか?
ミックスインは、複数の継承またはより多くのクラス構成の方法と見なされますか?
「クラス構成よりもオブジェクト構成を優先する」(またはその逆) ガイドラインもありますか?

オブジェクト構成でも機能する場合に mixin を使用 (または悪用) する例をいくつか見てきましたが、どちらが優れているかは常にわかりません。それらを使用して非常に類似したことを達成できるように思えますが、いくつかの違いもあります。いくつかの例:

• 可視性 - ミックスインを使用すると、すべてがパブリック API の一部になりますが、コンポジションの場合はそうではありません。
• 冗長性 - ほとんどの場合、ミックスインは冗長性が低く、使いやすいですが、常にそうであるとは限りません (たとえば、複雑な階層で自己型も使用する場合)

短い答えが「場合による」であることは知っていますが、おそらく、これまたはそれが優れている典型的な状況がいくつかあります。

これまでに思いついたガイドラインの例をいくつか示します (2 つの特性 A と B があり、A が B のいくつかのメソッドを使用したいと仮定します)。

• A の API を B のメソッドで拡張したい場合は mixin、それ以外の場合はコンポジションです。しかし、作成しているクラス/インスタンスがパブリック API の一部でない場合は役に立ちません。
• ミックスインを必要とするいくつかのパターン (例: Stackable Trait Pattern )を使用したい場合は、簡単に決定できます。
• 循環依存関係がある場合は、自己型の mixin が役立ちます。(私はこの状況を回避しようとしますが、必ずしも簡単ではありません)
• 動的な実行時の決定が必要な場合は、合成を行う方法、次にオブジェクトの合成を行います。

多くの場合、mixin の方が簡単 (および/または冗長度が低い) ように見えますが、"God クラス" や、artima の 2 つの記事: part 1、part 2 (BTW it他の問題のほとんどは関連性がなく、scala にはそれほど深刻ではないように思えます)。

このようなヒントは他にありますか？

私は定期的に次の問題に直面しているのを目にします。ある種のマーカーインターフェイス（簡単にするために使用しましょうjava.io.Serializable）といくつかのラッパー（アダプター、デコレーター、プロキシなど）があります。ただし、シリアライズ可能なインスタンスを別のインスタンス（シリアライズ可能ではない）でラップすると、機能が失われます。List実装で実装できるjava.util.RandomAccessでも同じ問題が発生します。それを処理するための優れたOOP方法はありますか？