Decoratorデザインパターンは、クロスカッティングに関する懸案事項を実施するための優れた出発点です。
まず、問題のサービスをモデル化するインターフェイスを定義する必要があります。それでは、クロスカッティングに関する懸念を全く考慮せずに、そのサービスの本当の機能を実装します。
次に、他のインスタンスをラップする装飾クラスを実装し、希望するクロスカッティングの問題を実装できます。
このアプローチは、Plain Old C#Objects(POCO)で完全に実装することができ、余分なフレームワークを必要としません。
ただし、すべての余分なデコレータの作成に飽きた場合は、フレームワークを使用することができます。明示的なAOPフレームワークに関する経験はありませんが、Castle WindsorのようなほとんどのDIコンテナはAOPのような機能を提供します。
デコレータの使用例を次に示します。あなたは次のインタフェースを持っているとしましょう:あなたはDoStuff操作をログに記録したい場合は、
public class ConsoleThing : IMyInterface
{
public void DoStuff(string s)
{
Console.WriteLine(s);
}
}
:
public interface IMyInterface
{
void DoStuff(string s);
}
あなたの具体的な実装には、コンソールに文字列を書き込むなど、非常に興味深い何かをすること
public class LoggingThing : IMyInterface
{
private readonly IMyInterface innerThing;
public LoggingThing(IMyInterface innerThing)
{
this.innerThing = innerThing;
}
public void DoStuff(string s)
{
this.innerThing.DoStuff(s);
Log.Write("DoStuff", s);
}
}
あなたは、キャッシングデコレータかそこらのセキュリティを実装し、1、およびちょうどWRのように、新しいデコレーターを書き続けることができ
:あなたは今、ロギングデコレータを実装することができますそれらをお互いの周りにap。
注:静的インターフェイスはほとんどお勧めできません。そのため、Log.Writeインターフェイスはお勧めできませんが、単にプレースホルダとして意味します。実際の実装では、私はLoggingThingにILoggerインターフェースのいくつかを注入します。
私はデコレータも考慮しました。メソッドを簡潔にしておけば、私が提案したソリューションの例から期待されるコントロールの細かさを犠牲にすることはありません。 デコレータを好む理由はありますか?デコレーションされたクラスはクロスカッティングの問題を認識する必要がないためです。 –
これは、あなたがそれらを扱うときに懸念を横断するためのあなたの好ましい解決策ですか? –
私は実際の実装をきれいにきれいに保つので、戦略の注入に比べてDecoratorを優先します。私はしばしばそれを好むが、時折、例えば、ウィンザー城。 –