Programate algo - Programming Blog/Blog de Programación

Versión en inglés / English version Supongamos que: Tenemos una clase que queremos desdoblar en subclases La futura clase base tiene eventos El refactoring nos lleva a la necesidad de que desde una clase derivada haya que hacer un RaiseEvent de un evento de la clase base. Cuando intentemos hacer lo indicado en el punto 3, nos surgirá un error de compilación diciendo que una clase derivada no puede lanzar eventos de la clase base. Para resolver esto, agregamos un método protected en la clase base que encapsule el RaiseEvent de marras, y en la clase derivada lo invocamos usando MyBase. Así: En la clase base (Los parámetros son a gusto nuestro): Protected Overridable Sub OnMessageGenerated(ByVal NewSender As Object, ByVal NewMessage As String) RaiseEvent MessageGenerated(NewSender, New MessageEventArgs(NewMessage)) End Sub Y en la clase derivada 'Hacer cosas... 'Quiero lanzar el evento de la clase base MyBase.OnMessageGenerated( Me, "Message" ) ...

Versión en inglés / English version En la entrada anterior, vimos como generar un evento desde una clase C++ nativa que tiene un wrapper C++/CLI como interfaz hacia .NET en el caso general en que deseamos pasar información extra en el evento, y dicha info no es de un tipo primitivo (o sea, un tipo que no conocen tanto C++ como .NET). Si sólo queremos pasar un float, un int, o cualquier tipo que conozcan tanto C++ como .NET, el método que vimos antes se simplifica un poco. En la clase nativa, definimos, por comodidad, un tipo puntero a función: typedef <retorno> ( __stdcall * PFOnEventoCallback )( <parametros> ); En la misma clase, declaramos un atributo del tipo definido en 1): PFOnEventoCallback m_FireEvento; Dentro de la clase nativa, donde querramos disparar el evento: m_FireEvento( <parametros> ); (Es buena idea inicializar m_FireEvento en NULL y validar que sea distinto de NULL antes de hacer el fir...

Versión en inglés / English version Supongamos que queremos generar un evento desde una clase C++ nativa que tiene un wrapper C++/CLI como interfaz hacia .NET. Supongamos el caso general en que deseamos pasar información extra en el evento, y dicha info no es de un tipo primitivo (o sea, un tipo que no conocen tanto C++ como .NET). En la clase nativa, definimos, por comodidad, un tipo puntero a función: typedef <retornoNativo> ( __stdcall * PFOnEventoCallback )( <parametrosNativos> ); En la misma clase, declaramos un atributo del tipo definido en 1): PFOnEventoCallback m_FireEvento; Dentro de la clase nativa, donde querramos disparar el evento: m_FireEvento( <parametrosNativos> ); (Es buena idea inicializar m_FireEvento en NULL y validar que sea distinto de NULL antes de hacer el fire) Ahora debemos exponer un setter para este atributo, de este estilo: void CClaseNativa::registerOnEvento...

Versión en inglés / English version En C++, el patrón Observador (también conocido como Publisher/Subscriber) es usualmente implementado como se sugiere en la biblia de los patrones de diseño: Gang of Four Dicha implementación requiere que el observador y el observado implementen sendas interfaces, de modo que cuando el observado cambie, notifique a todos sus observadores. De más está decir que esto puede hacerse de la misma forma en C#, considerando que C# no permite herencia múltiple, pero sí la implementación de más de una interfaz. Sin embargo, puede decirse que en C# el patrón Observador viene implementado en el propio lenguaje, a través de los mecanismos de delegates y eventos. Supongamos el siguient caso genérico: tenemos una clase del modelo que es observada por una clase de la vista. El patrón MVC nos dice que la vista puede tener una referencia al modelo, pero la dependencia inversa es síntoma de mal diseño. Es ahí donde el patrón observador viene al rescate...