Programate algo - Programming Blog/Blog de Programación

Spanish version / Versión en Español In C++, the Observer design pattern (also known as Publisher/Subscriber) is usually implemented as suggested in the bible of design patterns . This implementation requires that Observer and Observed implement the IObserver and IObserved interfaces, so that when Observed changes, all its registered Observers are notified. Needless to say, this can be done the same way in C#. However, this is not necessary since the Observer pattern is implemented in the C# language itself, with its delegates and events constructs. Suppose we want to use this to implement the MVC architecture pattern in our C# application. The MVC rationale says that View objects can reference Model objects, but not the other way around. So how does the model communicate with the view? Using the Observer Pattern. First, in our Model class, we must declare the Event which will be triggered when the Model changes. Then, we must define the delegate associated to this e...

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...

Spanish version / Versión en Español The following is a (quite) short summary of this MSDN article Firstly, it is of vital importance to understand that a Garbage Collected environment such as Managed .NET is not immune to memory leaks. One of the reasons for this is the fact that .NET's Garbage Collector only disposes objects which are no longer referenced by any other object. Ergo, if an object's reference count does not reach zero because of a dangling reference, the GC won't save us. On the other hand, when we talk about .NET applications which run on Windows, said applications usually consume Operating System resources (bitmaps, thread handles, critical sections, etc). These should be, ideally, released as soon as they are no longer needed. The author of the MSDN article mentions a ninja technique to hunt down leaks: Nevertheless, he prefers using higher level tools, such as these Usual causes for memory leaks in .NET: Static referen...

Versión en inglés / English version Lo siguiente es un (muy) breve resumen de un artículo de la MSDN: Artículo original En primer lugar, es vital entender que los lenguajes con recolector de basura como .NET no son inmunes a las pérdidas de memoria. Una de las razones de ello es que el recolector sólo libera memoria que ya no es referenciada: si el contador de referencias de un objeto no llega a cero porque dejamos una referencia colgada, el recolector no nos salvará. Por otro lado, cuando hablamos de aplicaciones .NET que corren en Windows, dichas aplicaciones suelen consumir diversos recursos del SO, que idealmente deben ser liberados apenas dejan de ser usados. El autor del artículo menciona una técnica "ninja" para eliminar pérdidas: The ninja way :) Aunque él prefiere usar herramientas de más alto nivel, como las mencionadas aquí: Herramientas Copantes Causas usuales de memory leaks en .NET: Referencias estáticas (atributos estáticos y...