Head First Design Patterns の本を読み、他の多くのデザイン パターンを使用した後、私は Observer パターンを理解しようとしています。これは、.NET Framework のイベントを使用して既に実装されていませんか?
8 に答える
はい、そうです。オブザーバー パターンは、パブリッシュ/サブスクライブ パターンとも呼ばれます。これは、まさにイベントで実行できるパターンです。
そうです、Anders Heljsberg の意図は、Delphi での経験に基づいて、C# のイベントでオブザーバー パターンを第一級の言語機能にすることでした。Anders は、 Software Engineering Radioの優れたインタビューで、このことやその他の設計意図を明らかにしています。
はい、同じです。
注: イベントを本当に理解したい場合は、オブザーバー パターンを学習し、しばらくの間自分で実装することをお勧めします。それを完全に理解したら、それを自分で行うのをやめて、他に本当に必要がない限り、専門的で十分に文書化された実装を使用してください。
はい。ただし、オブザーバー パターンを明示的にプログラミングし、デリゲートとイベントを使用しないと、コードのデバッグが容易になります。
違いを考えてみましょう:
public void NotifyObservers()
{
foreach(Product product in ProductList)
{
if (product is IProductObserver)
{
product.Update(this)
}
}
}
ここでは、リスト内のどの製品が変更の通知を受けるかが非常に明確です。デバッグ中に ProductList を調べることができます...
デリゲートとイベントを使用すると、イベントを処理するために実際に「サブスクライブ」された「デリゲート」の数を確認するのが面倒になる場合があります。
そうです、イベントはオブザーバー パターンの実装です。ただし、柔軟性を高めるため、または単にイベントを発生させる構文を回避するために、独自の記述を行っている人々の議論を読んだことがあります。
Microsoft自身は、イベントとデリゲートを使用することが Observer パターンを適用する C# の方法であると述べています。イベントとデリゲートにいくつかの基本的な命名規則を使用して、彼らは独自のパターンを「イベント パターン」と名付けました。
「イベント パターン」については、MSDN ライブラリの「オブザーバー デザイン パターンの探索」記事内で説明されています。
イベントとデリゲートに基づいて、FCL はオブザーバー パターンを非常に広範囲に使用します。FCL の設計者は、このパターンの固有の力を完全に認識し、フレームワーク全体のユーザー インターフェイスと非 UI 固有の機能の両方に適用しました。ただし、この使用法は、フレームワーク チームがイベント パターンと呼んでいるベース オブザーバー パターンのわずかなバリエーションです。一般に、このパターンは、イベント通知プロセスに関係するデリゲート、イベント、および関連するメソッドの正式な命名規則として表現されます。Microsoft は、イベントとデリゲートを利用するすべてのアプリケーションとフレームワークでこのパターンを採用することをお勧めしますが、CLR または標準コンパイラでは強制されません。
この Observer パターンの調査に基づいて、このパターンが、機能 (UI など) に関係なく、アプリケーション内のオブジェクト間の明確な境界を確保するための理想的なメカニズムを提供することは明らかです。コールバック (IObserver および IObservable インターフェイスを使用) を介して実装するのは非常に簡単ですが、デリゲートとイベントの CLR の概念は、"重労働" の大部分を処理し、サブジェクトとオブザーバー間の結合レベルを低下させます。
最新の言語のほとんどは、一部の設計パターンをネイティブでサポートしています。言語は、明示的に実装する必要なくネイティブにサポートするパターンが多いほど優れていると主張されてきました。また、Lisp はこの点で優れていると主張されてきました。ジェフもそれについて何か言いたいことがありました。
いいえ、それらは同じ意図を達成しますが、それらは異なります。オブザーバー パターンは、関数型プログラミングで簡単に実現できたものを実現するためのオーバー デザインのかなりのハックであり、.NET イベントは関数型プログラミングを使用して同じ目標を達成していると言えます。