Skip to main content

Posts

Showing posts with the label design pattern

VBA versus .NET

Decorator Pattern

This is an example of the Decorator pattern, in this case a decorator for ObservableCollection.  Working with WPF and ObservableCollection using threads, one will run into the problem whereby the ObservableCollection cannot be updated from outside the owning thread; Delegates and Invoke will not work. A solution is to contain and expand the class, as is done in this example on michIG's Blog . This linked file contains the original code in C#, as well as the same code converted to VB.NET. Salient Characteristic(s) Sets an internal pointer to the decorated object, sending method calls and property actions to the internal object Extends the object by wrapping it and adding some aspect handled by the decorator Code using System; using System.Collections.ObjectModel; using System.Windows.Threading; using System.Collections.Specialized; using System.ComponentModel; namespace DesignPatterns {     /// <summary>       /// This class is an...

Bridge Pattern

A bare-bones, generic implementation of the bridge pattern, using inheritance, polymorphism, and abstraction.  Salient Characteristic(s) Decouple classes, allowing them to vary independently Useful when frequent changes are made to classes Code namespace DesignPatterns {     /// <summary>     /// The implementor: the abstract class, and concrete implementation of one side of the relation     /// </summary>      public interface IBridgeAbstraction     {         void Build();     }          abstract class BridgeAbstraction : IBridgeAbstraction     {         public abstract void Build();     }     class ConcreteBridge1 : BridgeAbstraction     {         public override void Build()         {         }   ...

Abstract Cat Factory (Amusement)

A friend amusingly posted on Facebook a retro photograph of four (4) 'designers' around a cat, with the caption alluding to designing hats for cats, and so I decided to make, somewhat incongruously, an abstract cat factory, which varies by the location of the cat..   Salient Characteristic(s) Classes derived from abstract types Class creates derived (concrete) classes based on type required Code namespace DesignPatterns {     public enum Location     {         Kitchen,         Bedroom,         LivingRoom     }     public enum Amusements     {         String,         Mouse,         Food,         Sleep     }          public abstract class Feline     {         public abstract Feline HereKittyKitty...

Multiton

A fairly simple example of the multiton pattern, with a private constructor, and a tracker for created objects, the name being an integer identifier. Salient Chacteristic(s) A private keyed list for tracking objects A private constructor Named objects Code using System.Collections.Generic; using System.Linq; namespace DesignPatterns {     public class Multiton     {         //read-only dictionary to track multitons         private static IDictionary<int, Multiton> _Tracker = new Dictionary<int, Multiton> { };         private Multiton()         {         }         public static Multiton GetInstance(int key)         {             //value to return             Multiton item = null;              ...

Singleton

The Singleton design pattern seems generally frowned upon, except for use in logging classes.  Below are several variants of the Singleton design pattern, of which, only the thread-safe version merits attention: Salient Chacteristic(s) A private constructor Static variable for self-tracking Three (3) variants Eager Lazy Thread-safe (Double-checked Locking) Code namespace DesignPatterns {     //double-checked locking singleton     //required for threaded environments     public class DoubleCheckingSingleton     {         private static volatile DoubleCheckingSingleton _Instance = null;         private static object _SyncRoot = new object();              //Private constructor prevents instantiation from other classes         private DoubleCheckingSingleton()         {        ...