➕ 👃🏾 🥨 .NETとデザインパターン 🔗 🍖 🧜🏽

設計パターンまたはパターンは、頻繁に発生するコンテキスト内の設計問題の解決策である反復可能なアーキテクチャ設計です。

この定義を何千回も聞いたことがあるようです...用語とパターンを知ることに加えて、実際のプロジェクトでそれらがどのように使用されているかを知ることは興味深いです。

この記事では、.NETで使用される最も一般的なパターンのいくつかについて説明します。それらのいくつかは、.NETインフラストラクチャに深く統合されていますが、BCLで基本クラスを設計するときに単純に使用されるものもあります。

1ダース以上の本がデザインパターンに専念していますが、1冊の本が際立っており、これは有名な本「ギャングオブフォー」です。したがって、状況をよりよく理解するために、この本から簡単な説明を提供します。

次の6つのパターンについて説明します。

オブザーバー
イテレータ;
デコレータ;
アダプター;
工場
戦略。

それでは始めましょう。

オブザーバー

おそらく、.NETで使用される最も有名なパターンはオブザーバーです。それはデリゲートの基礎であるため知られています。デリゲートは、当初から.NETの不可欠な部分でした。 .NETオブジェクトモデルへの貢献に感謝することは難しくありません。特に、後のバージョン（ラムダ、クロージャなど）で何が流されたのかを考えると、難しいことではありません。

パターンの目的は、GOFのオブザーバーです。1つのオブジェクトの状態が変化すると、オブジェクトに依存するすべてのオブジェクトに通知され、自動的に更新されるように、オブジェクト間の1 対多の関係を定義します。

C＃でのこのパターンの最も単純な実装は、次のようになります。

単純なオブザーバー

public interface IObserver //   { void Notify(); } public abstract class Subject //  { private List<IObserver> observers = new List<IObserver>(); public void Add(IObserver o) { observers.Add(o); } public void Remove(IObserver o) { observers.Remove(o); } public void Notify() //    { foreach (IObserver o in observers) o.Notify(); } }

.NETプラットフォームで述べたように、オブザーバーの抽象化はデリゲートによって実装されます。デリゲートとのより便利な作業のために、イベントはC＃で使用されます。次の例では、それらを使用します。

.NETのオブザーバー

 public delegate void MyEventHandler(); //    public class Subject { public Subject() { } public MyEventHandler MyEvent; //  public void RaiseEvent() //       { MyEventHandler ev = MyEvent; if (ev != null) ev(); } } static void Main(string[] args) { Subject s = new Subject(); s.MyEvent += () => Console.WriteLine("Hello habrahabr"); //   s.MyEvent += () => Console.WriteLine("Hello world"); //   s.RaiseEvent(); //    Console.ReadKey(); }

顔の観察者パターンとの類似。イベントはサブジェクトとして機能し、デリゲートはオブザーバーとして機能します。

ご注意

上記のコードには1つの欠点があります。ラムダ式を使用する場合、デリゲート、つまりコードを切断することはできません。

 s.MyEvent -= () => Console.WriteLine("Hello habrahabr");

別のインスタンスであるため、このデリゲートは削除されません。デリゲートをさらに切り離すには、デリゲート（ラムダ式）を変数に保存する必要があります。

 static void Main(string[] args) { Subject s = new Subject(); MyEventHandler myEv1 = () => Console.WriteLine("Hello habarhabr"); MyEventHandler myEv2 = () => Console.WriteLine("Hello world"); s.MyEvent += myEv1; s.MyEvent += myEv2; s.MyEvent -= myEv1; s.RaiseEvent(); //      Console.ReadKey(); }

.NET 4.0では、オブザーバーパターンを直接実装するためのインターフェイスが導入されました。次のようになります。

 public interface IObservable<out T> { IDisposable Subscribe(IObserver<T> observer); } public interface IObserver<in T> { void OnCompleted(); void OnError(Exception error); void OnNext(T value); }

ご覧のとおり、IObservableインターフェイスの実装は、オブザーバーとは少し異なります。オブザーバーを追加および削除するメソッドを持つ代わりに、オブザーバーを登録するメソッドのみを持っています。このメソッドは、プロバイダーが通知の送信を停止する前に、オブザーバーが通知をいつでもキャンセルできるようにするIDisposable実装を返します。これで、ラムダ式を使用し、Disposeメソッドを呼び出してラムダ式を切断できます。

ご注意

イテレータ

.NETでの使用がそれほど一般的ではない次のパターンは、イテレータです。

GOFの反復子パターンの目的：内部表現を明かすことなく、複合オブジェクトのすべての要素に順次アクセスする方法を提供します。

.NETプラットフォームでは、IEnumerableとIEnumeratorの2つのインターフェイスがイテレータパターンの実装を担当します。

 public interface IEnumerable { IEnumerator GetEnumerator(); } public interface IEnumerator { object Current { get; } bool MoveNext(); void Reset(); }

およびそれらの一般化された類似体：

 public interface IEnumerable<out T> : IEnumerable { IEnumerator<T> GetEnumerator(); } public interface IEnumerator<out T> : IDisposable, IEnumerator { T Current { get; } }

foreachループを使用してエンティティを反復処理できるようにするには、IEnumerable <>インターフェイスを実装し、イテレータ自体（IEnumerator <>インターフェイスを実装するクラス/構造体）を作成する必要があります。

yieldキーワードを使用してC＃2.0でイテレータブロックが出現したことを考慮すると、IEnumerator <>インターフェイスを実装するカスタムタイプの作成はほとんど行われません（コンパイラがこれを行います）。

foreachループは、イテレーターパターンと並んで機能します。次のコード

 foreach (var item in Enumerable.Range(0, 10)) { Console.WriteLine(item); }

これはコードの構文糖衣です：

 IEnumerator<int> enumerator = Enumerable.Range(0, 10).GetEnumerator(); try { while (enumerator.MoveNext()) { int item = enumerator.Current; Console.WriteLine(item); } } finally { if (enumerator != null) { enumerator.Dispose(); } }

したがって、イテレータパターンは、言語構成（foreach）が使用するため、C＃言語の基礎となります。

ご注意

foreachループは、反復可能なエンティティがIEnumerableインターフェイスを実装することを実際に必要としないという事実（ただし、特定のシグネチャを持つ特定のメソッドの存在のみを必要とする）は多くの人によって書かれているので、説明しません。 Sergey Teplyakov SergeyTには、foreachサイクルの作業に特化した優れた投稿があります。

foreachループに関して、.NETにはいくつかの最適化があります。イテレータオブジェクトは各反復で作成されるため、特に複数のforeachループがある場合、ガベージコレクションに悪影響を与える可能性があります。したがって、配列と文字列（CLRに深く統合された型）を反復すると、foreachループは通常のforループに展開されます。

ご注意

デコレータ

パターンNo. 3-オブジェクトのデコレーター。

GOFのパターンデコレータの目的：オブジェクトに新しい責任を動的に追加します。機能を拡張するためのサブクラス化の柔軟な代替手段です。

.NETのデコレータは、System.IO.Streamクラスとその子孫によって表されます。次のコードを検討してください。

 public static void WriteBytes(Stream stream) { int oneByte; while ((oneByte = stream.ReadByte()) >= 0) { Console.WriteLine(oneByte); } } static void Main(string[] args) { var memStream = new MemoryStream(new byte[] { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9 }); WriteBytes(memStream); var buffStream = new BufferedStream(memStream); WriteBytes(buffStream); Console.ReadLine(); }

WriteBytesメソッドはどのストリームでも機能しますが、常にこれを効率的に行うとは限りません。ディスクから1バイトを読み取ることはあまり良くないので、BufferedStreamクラスを使用できます。このクラスは、データをブロック単位で読み取り、すぐにそれらを返します。コンストラクターのBufferedStreamクラスは、Streamタイプ（任意のストリーム）を受け入れ、それにより、より効率的なシェルでそれをラップ（装飾）します。 BufferedStreamは、ReadやWriteなどのStreamクラスの基本メソッドを再定義して、より多くの機能を提供します。

System.Security.Cryptography.CryptoStreamクラスを使用すると、オンザフライでストリームを暗号化および復号化できます。また、コンストラクターでStream型のパラメーターを受け入れ、シェルでそれをラップします。

どのストリームでも、データアクセスインターフェイスを変更せずにBufferedStreamで囲むことにより、効率的に読み取る機能を追加できます。機能を継承するのではなく、「装飾」するだけなので、継承を使用した場合のように、コンパイル時ではなく実行時に実行できます。

アダプター

GOFのアダプターパターンの目的： 1つのクラスのインターフェイスを、クライアントが期待する別のクラスのインターフェイスに変換します。このアダプターにより、クラスは互換性のないインターフェースで動作できますが、これがなければインターフェースは機能しませんでした。

COMと.NETの内部アーキテクチャは異なります。したがって、1つのインターフェイスを別のインターフェイスに適合させる必要があります。 CLRは、シェルと呼ばれるランタイム（RCW）と呼ばれる中間体を介してCOMオブジェクトへのアクセスを提供します。

ランタイムは、このオブジェクトへの既存の参照の数に関係なく、COMオブジェクトごとに1つのランタイムラッパーを作成します。

他の操作の中でも、シェルと呼ばれるランタイムは、シェルにラップされたオブジェクトに代わって、マネージコードとアンマネージコードの間でデータをマーシャリングします。特に、クライアントとサーバー間で交換されるデータが異なる方法で提示される場合、呼び出されたランタイムシェルは引数をマーシャリングし、メソッドの値を返します。

たとえば、.NETクライアントが引数の一部としてアンマネージオブジェクトにStringを渡すと、シェルはこの文字列をBSTR（.NETで文字列の機能を説明した投稿）に変換します。 COMオブジェクトが管理対象の呼び出し元にBSTRデータを返す場合、呼び出し元は文字列データを受け取ります。クライアントとサーバーの両方が、わかりやすい方法でデータを送受信します。

実際、RCWは、あるインターフェースを別のインターフェースに変換するアダプターです。

工場

5番目のパターンは一種の工場です。

GOFのファクトリパターンの目的：特定のクラスを指定せずに相互接続または相互依存オブジェクトのファミリを作成するためのインターフェイスを提供します。

System.Convertクラスには、コンストラクターを明示的に呼び出さずにオブジェクトを作成できる静的メソッドのセットが含まれており、ファクトリーとして機能します。たとえば、整数を論理値に変換するには、整数を呼び出してConvert.ToBooleanメソッドのパラメーターとして渡すことができます。このメソッドの戻り値は、数値がゼロ以外の場合はtrue、それ以外の場合はfalseになります。他の型変換方法も同様に機能します。

オブジェクトの新しいインスタンスを作成するためのこのような戦略は、ファクトリパターンとして知られています。コンストラクターを呼び出さずに、ファクトリに目的のオブジェクトを作成するように依頼できます。したがって、Factoryパターンは、オブジェクト作成の複雑さを隠すことができます。オブジェクト作成の詳細を変更する場合は、ファクトリー自体を変更するだけでよく、コンストラクターが呼び出されるコード内のすべての場所を変更する必要はありません。

型情報と組み合わせたActivator.CreateInstanceメソッドは、抽象クラスファクトリを実装します。任意のタイプのインスタンスを作成できるもの。

戦略

パターンの目的は、GOFの戦略です。アルゴリズムのファミリーを定義し、それぞれをカプセル化して、交換可能にします。この戦略により、アルゴリズムを使用する顧客に関係なくアルゴリズムを変更できます。

この単純なパターンを適用する良い例は、配列のソートです。 Array.Sortメソッドのオーバーロードの1つは、IComparable型のパラメーターを取ります。このインターフェイスを使用して、互いに独立しており、簡単に交換できる、いわゆる戦略用の一連のソートアルゴリズムを作成できます。

 public interface IComparable<T> { int CompareTo(T other); }

並べ替えコードは、要素比較アルゴリズムとは実質的に独立しており、変更されない場合があります。

これには、IComparableインターフェイスも受け入れるArray.BinarySearchメソッドと、Predicateデリゲートが受け入れるArray.Findメソッドも含まれます。したがって、さまざまなデリゲート（戦略）を変更することで、メソッドの動作を変更し、必要な結果を取得できます。

一般的に、戦略パターンは常に使用されます。この記事を書く前に、異なるコンパレーターで配列を並べ替えるときに戦略パターンを使用することを考えていませんでした。

おわりに

.NET Frameworkで使用されているパターンのいくつかを見てきたので、作業中のコードでそれらを認識しやすくする必要があると思います。 C＃言語と.NETインフラストラクチャ全般へのイベントとイテレータの貢献を高く評価しないことは難しいので、これが古典的なデザインパターンの実装であることを知ることは単に必要です。

読んでくれてありがとう。この記事がお役に立てば幸いです。

.NETとデザインパターン

オブザーバー

イテレータ

デコレータ

アダプター

工場

戦略

おわりに

More articles: