私は上級レベルの開発者ですが、正式なトレーニングはあまり受けていません。多くのデザインパターンを使用し、開発者としての数年間にそれらが使用されているのを見てきましたが、誰も言いたくありませんでした。「ああ、これはオブザーバーパターン、またはこれはシングルトンパターンです。」
いくつかのデザインパターンを読んで、オブザーバーパターンに出くわしました。これは、.NETFrameworkイベントの動作と非常によく似ているようです。私はこれについて基本的な何かが欠けていますか?
私は上級レベルの開発者ですが、正式なトレーニングはあまり受けていません。多くのデザインパターンを使用し、開発者としての数年間にそれらが使用されているのを見てきましたが、誰も言いたくありませんでした。「ああ、これはオブザーバーパターン、またはこれはシングルトンパターンです。」
いくつかのデザインパターンを読んで、オブザーバーパターンに出くわしました。これは、.NETFrameworkイベントの動作と非常によく似ているようです。私はこれについて基本的な何かが欠けていますか?
.NETイベントモデルは、共通言語ランタイムでのオブザーバーパターンのほぼ統合された実装です。.NET言語は、フレームワークの組み込みサポートを使用して、言語固有の方法でオブザーバーを直接実装します。
ほとんどのプログラミング言語では、オブザーバーパターンにはカスタマイズされた開発またはライブラリが必要です。
これは、C#、VB.NET、およびCLRを使用するために構築された他のほとんどの言語の言語の一部として無料で提供されます。
MSDNから
FCL で公開されている型に精通している人は、IObserver、IObservable、または ObservableImpl 型がフレームワークに存在しないことに気付くでしょう。それらが存在しない主な理由は、CLR によってそれらが時代遅れになるという事実です。これらのコンストラクトは .NET アプリケーションで確実に使用できますが、デリゲートとイベントの導入により、Observer パターンをサポートする専用の特定の型を開発しなくても、このパターンを実装する新しい強力な手段が提供されます。実際、デリゲートとイベントは CLR のファースト クラス メンバーであるため、このパターンの基盤は .NET Framework のまさにコアに組み込まれています。そのため、FCL はその構造全体で Observer パターンを広範囲に使用します。
Java 1.1 以降のような多くのイベント モデルや .NET イベント モデルは、基本的に Observer パターンの実装です。
これは、イベント処理のために C でコールバック メソッドを使用するなど、古いメカニズムにも適用されることに注意してください。これは同じ意図ですが、実装がわずかに異なります。
なぜ違いがあるに違いないと思いますか?
.NETデザイナーもデザインパターンを読んでいると思いませんか?
実際、オブザーバーパターン(本のすべてのように)は、Gof4によって分類され、名前が付けられるずっと前からよく知られていました。これは、.Netイベントモデル、Win32およびWin16イベントモデル、およびおそらく他の多くのモデルを実装するために使用されました。