Después de leer el libro de Patrones de diseño de Head First y de utilizar otros patrones de diseño, intento comprender el patrón Observer. ¿No es esto ya implementado usando Eventos en .NET Framework?En C#, ¿no está ya implementado el patrón de observador usando Eventos?
Sí, lo es. El patrón de observador también se llama patrón de publicación/suscripción, que es exactamente lo que los eventos le permiten hacer.
Así es, los eventos son una implementación del patrón de observador. Sin embargo, he leído discusiones de personas que todavía escriben las suyas, para darles más flexibilidad o, simplemente, para evitar la sintaxis de la generación de eventos.
Sí, es idéntico.
Una nota: si realmente quiere entender los eventos, recomiendo aprender el patrón de observador e implementar por sí mismo una por un tiempo. Una vez que lo comprende completamente, deje de hacerlo usted mismo y utilice la implementación profesional y bien documentada a menos que tenga una necesidad real de hacerlo de otra manera.
yo diría que sí, que era la intención de Anders Heljsberg para hacer que el patrón de observador una característica del lenguaje de primera clase con eventos en C#, en base a su experiencia con Delphi. Anders aclara esta y otras intenciones de diseño en una excelente entrevista en Software Engineering Radio.
mayoría de los lenguajes modernos tienen soporte nativo para algunos de los patrones de diseño. Se ha argumentado que los idiomas son mejores cuanto más patrones soportan de forma nativa sin la necesidad de implementarlos explícitamente, y que Lisp es excelente en este sentido. Jeff también tenía something to say.
Sí, pero la programación del patrón de observador de manera explícita y por lo tanto no utilizar delegados y eventos puede dar lugar a una depuración más sencilla de su código.
considerar la diferencia:
public void NotifyObservers()
{
foreach(Product product in ProductList)
{
if (product is IProductObserver)
{
product.Update(this)
}
}
}
Aquí es muy claro cuáles son los productos en la lista de ser notificado de un cambio. Mientras que la depuración se puede inspeccionar la lista de productos ...
Con el uso de los delegados y eventos puede ser más engorroso para averiguar cómo eran en realidad muchos "delegados" "suscrito" para controlar el evento.
no me gusta la idea de alentar a los desarrolladores a volver a implementar en lugar de reutilizar. –
¿Puede profundizar en eso? Quiero decir, en ambos casos los desarrolladores tienen que implementar el patrón. He puesto esto como un ejemplo explícito básicamente porque estoy de acuerdo con Dinah en que si realmente quieres entender el patrón del observador, es mejor que primero lo construyas tú mismo e ir a eventos después. – Hace
No, lograr la misma intención, sin embargo, son diferentes. Diría que el patrón Observer es un hack over del diseño para lograr algo que podría haber logrado fácilmente con la programación funcional, y que los eventos .NET usan programación funcional para lograr el mismo objetivo.
Microsoft Propio afirma que el uso de eventos y delegados es la forma C# de aplicar el Patrón de observador. Usando algunas convenciones de nomenclatura básicas para eventos y delegados, nombraron su propio patrón como "Patrón de evento" que hace exactamente lo mismo proporcionando algunas ventajas adicionales sobre el Observer Pattern clásico.
"Patrón de eventos" se describe en la biblioteca de MSDN dentro de la "Exploración de la Diseño Observador Patrón" artículo.
Basada en hechos y delegados, la LCF utiliza el patrón Observador sobradamente. Los diseñadores de la FCL se dieron cuenta completamente del poder inherente de este patrón, aplicándolo tanto a la interfaz de usuario como a las características no relacionadas con la IU en todo el Marco. Este uso, sin embargo, es una pequeña variación en el patrón de Observador base, que el equipo del Marco ha denominado Patrón de Evento. En general, este patrón se expresa como convenciones formales de nomenclatura para delegados, eventos y métodos relacionados que participan en el proceso de notificación de eventos. Microsoft recomienda que todas las aplicaciones y los marcos que utilizan eventos y delegados adoptan este patrón, aunque no hay una ejecución en el CLR o compilador estándar
Sobre la base de este examen del patrón Observer, debería ser evidente que este patrón ofrece un mecanismo ideal para asegurar límites nítidos entre objetos en una aplicación, independientemente de su función (UI o de otro tipo). Aunque es bastante simple de implementar a través de devoluciones de llamada (utilizando las interfaces IObserver e IObservable), los conceptos CLR de delegados y eventos manejan la mayoría de los "trabajos pesados", así como también disminuyen el nivel de acoplamiento entre el sujeto y el observador.
una respuesta ligeramente diferente a esta pregunta, ver http://stackoverflow.com/questions/1023329/observer-pattern-implemented-in-c-sharp-with-delegates – kmote