В C # разве шаблон наблюдателя уже не реализован, используя События?

Question

После прочтения книги Head First Design Patterns и использования ряда других шаблонов проектирования я пытаюсь понять шаблон Observer. Разве это уже не реализовано с использованием событий в .NET Framework?

Answer 1

Да, это так. Шаблон наблюдателя также называется шаблоном публикации / подписки, что и позволяет делать события.

Answer 2

Я бы сказал, что да, это было намерением Андерса Хелсберга сделать шаблон наблюдателя первоклассной языковой функцией с событиями в C #, основываясь на его опыте с Delphi. Андерс проясняет это и другие замыслы в отличном интервью на Software Engineering Radio .

Answer 3

Да, это идентично.

Примечание: если вы действительно хотите понять события, я рекомендую изучить шаблон наблюдателя и реализовать его некоторое время. Как только вы полностью это поймете, прекратите делать это самостоятельно и используйте профессиональную и хорошо документированную реализацию, если у вас нет реальной необходимости поступать иначе.

Answer 4

Да, но программирование шаблона наблюдателя явно и, следовательно, без использования делегатов и событий, может привести к более легкой отладке вашего кода.

Рассмотрим разницу:

public void NotifyObservers()
{
    foreach(Product product in ProductList)
    {
        if (product is IProductObserver)
        {
               product.Update(this)
        }
    }
}

Здесь очень ясно, какие продукты в списке получают уведомления об изменениях. Во время отладки вы можете проверить ProductList ...

С использованием делегатов и событий может быть более громоздким узнать, сколько "делегатов" было фактически "подписано" для обработки события.

Answer 5

Правильно, события - это реализация шаблона наблюдателя. Однако я читал дискуссии о людях, которые все еще пишут свои собственные, чтобы дать им больше гибкости или просто избежать синтаксиса событий.

Answer 6

Microsoft Сам утверждает, что использование событий и делегатов - это способ применения шаблона наблюдателя c #. Используя некоторые базовые соглашения об именах для событий и делегатов, они назвали свой собственный шаблон как «Шаблон события» , что делает то же самое, обеспечивая некоторые дополнительные преимущества по сравнению с классическим Наблюдателем шаблона .

«Шаблон событий» описан в библиотеке MSDN внутри статьи « Исследование шаблона проектирования наблюдателя ».

Ссылка MSDN Статья

Исходя из событий и делегатов, FCL довольно широко использует шаблон Observer. Разработчики FCL полностью осознали всю мощь этого шаблона, применив его как к пользовательскому интерфейсу, так и к функциям, не связанным с пользовательским интерфейсом, во всей среде Framework. Это использование, однако, является небольшим изменением базового шаблона Observer, который группа разработчиков назвала Шаблоном событий. В общем, этот шаблон выражается в виде формальных соглашений об именах для делегатов, событий и связанных методов, участвующих в процессе уведомления о событиях. Microsoft рекомендует, чтобы все приложения и платформы, использующие события и делегаты, использовали этот шаблон, хотя в CLR или стандартном компиляторе нет принудительного применения

На основании этого анализа шаблона Observer должно быть очевидно, что этот шаблон обеспечивает идеальный механизм для обеспечения четких границ между объектами в приложении, независимо от их функции (пользовательского интерфейса или иным образом). Хотя это довольно просто реализовать с помощью обратных вызовов (используя интерфейсы IObserver и IObservable), концепции CLR делегатов и событий обрабатывают большую часть «тяжелой работы», а также уменьшают уровень связи между субъектом и наблюдателем.

Answer 7

Нет, они достигают одного и того же намерения, однако они разные. Я бы сказал, что шаблон Observer - это слишком сложный проект для достижения того, чего вы могли бы легко достичь с помощью функционального программирования, и что в .NET-событиях используется функциональное программирование для достижения той же цели.

Answer 8

Большинство современных языков имеют встроенную поддержку некоторых шаблонов проектирования. Утверждалось, что языки лучше, чем больше шаблонов, которые они поддерживают изначально, без необходимости их явной реализации, и что Lisp превосходен в этом отношении. Джеффу было что-то сказать об этом тоже.