私は、任意のオブジェクトのプレゼンテーションと呼ぶものを定義できるフレームワークを開発しています。このようなプレゼンテーションは、オブジェクトの側面として理解できます。例:特定のアプリケーションのオブジェクトは、レンダリングエンジンによって視覚化する必要があります。オブジェクト自体のタイプを拡張する代わりに、オブジェクトからデータを読み取る(他のプレゼンテーションのコンテキストでデータを書き込むことができる)サービス(レンダリングエンジン)によって提供されるプレゼンテーションを提供します。
フレームワークは、機能を使用するために、いくつかのインターフェースがアプリケーションタイプによって実装されることを期待しています。ただし、アプリケーションがこれらのインターフェイスの実装を提供しない場合、フレームワークは自動的に型をサブクラス化し、次のようにこれらのインターフェイスのデフォルトの実装を追加します。
フレームワーク(マネージC ++):
namespace Spoc::Claire
{
public interface class IEntity
{
void DoSomething() ;
} ;
}
簡単なアプリケーション(C#)は次のとおりです。
namespace Spoc.Samples
{
class Hello
{
public Hello()
{
Console.WriteLine("Hello world") ;
}
static void Main(string[] args)
{
Entity.New(typeof(Hello)) ; // creates the "Hello" object within the context of the framework
}
}
}
フレームワークが動的アセンブリ内のリフレクションによって作成するものは次のとおりです。
namespace Internal
{
class Hello : Spoc.Samples.Hello, Spoc.Claire.IEntity
{
public void Hello()
{
// call the base class constructor
}
public void DoSomething()
{
// default implementation for IEntity
}
}
}
このオブジェクトはアプリケーションに返され、指定されたタイプから継承するため、制限なしで使用できます。
だから問題は何ですか?アプリケーションがタイプを「パブリック」として定義している場合は、すべて正常に実行されます。そうでない場合は、上記の例のように、TypeBuilder :: CreateType()メソッドから「Spoc.Samples.Helloタイプのアクセスが拒否されました」というTypeLoadExceptionが発生します。
一見すると、次のように言うかもしれません。まあ、あなたはプライベートクラスをそのアセンブリの外に拡張しようとしています。私の主張は次のとおりです。はい、私はプライベートクラスから派生していますが、動的アセンブリ内にあります。つまり、「RunAndCollect」のフラグが付けられているため、保存することはできません。したがって、タイプは他の場所では使用できません。 AppDomain。新しいタイプはプライベートのままであり、率直に言って、はるかに厳密な意味で、AppDomainの現在のインスタンスに対してプライベートであるため、理論的にはプライベートの原則に違反しません。
私は友達アセンブリのパラダイムをいじってみましたが、友情が厳密にオブジェクト指向の設計に違反しているという事実を除けば、動的アセンブリを友達として指定するのは難しいです。ReflectionPermission属性も見つかりましたが、それも停止しました。
私にアドバイスをくれる人はいますか?
PS:はい、フレームワークを利用しようとするすべてのオブジェクトはパブリックである必要があると言うことで、実用的な方法をとることができます。残念ながら、フレームワークは、暗黙の知識を持たせるべきではなく、基礎となる言語の可能性を必ずしも制限するべきではない手段と見なしています。