.NET Architecture & Development

The Proxy pattern is intended to provide you with a simple placeholder that takes the place of a more complex object  that may be invoked later. It  is a kind of "wrapper" that delegates to the real object.

The Proxy pattern is especially useful for situations where object creation is a time consuming process, and you do not want to instantiate such an object unless and until it is actually requested by the client. This is also known as the "lazy loading" principle.

Code examples (click to enlarge/collapse):

1. simple example
   class Program {     static void Main(string[] args)     {         Proxy proxy = new Proxy();         proxy.Request(); Console.ReadKey();     } } public class Proxy : Subject {     private RealSubject m_RealSubject;     public override void Request()     {         Console.WriteLine("I am proxy doing a 'lazy load'");         if (m_RealSubject == null)         {             m_RealSubject = new RealSubject();         }         m_RealSubject.Request();     } } public abstract class Subject {     public abstract void Request(); } public class RealSubject : Subject {     public override void Request()     {         Console.WriteLine(".. and I am the real subject.");     } }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

   class Program {     static void Main(string[] args)     {         Proxy proxy = new Proxy();         proxy.Request(); Console.ReadKey();     } } public class Proxy : Subject {     private RealSubject m_RealSubject;     public override void Request()     {         Console.WriteLine("I am proxy doing a 'lazy load'");         if (m_RealSubject == null)         {             m_RealSubject = new RealSubject();         }         m_RealSubject.Request();     } } public abstract class Subject {     public abstract void Request(); } public class RealSubject : Subject {     public override void Request()     {         Console.WriteLine(".. and I am the real subject.");     } }

2. real world example
   using System; class Program {     static void Main(string[] args)     {         Employee employee = new Employee(); Console.WriteLine("Employee name: {0}", employee.EmployeeName);         Console.WriteLine("Manager name : {0}", employee.Manager.ManagerName); Console.WriteLine("Loading manager..");         employee.Manager.Load();         Console.WriteLine("Manager name: {0}", employee.Manager.ManagerName);         Console.ReadKey();     } } public class Employee {     public string EmployeeName = "Employee";     public Manager Manager = new Manager(); } public class Manager : ManagerBase {     private RealManager m_RealSubject;     public override void Load()     {         if (m_RealSubject == null)         {             m_RealSubject = new RealManager();         }         m_RealSubject.Load();         ManagerName = m_RealSubject.ManagerName;     } } public abstract class ManagerBase {     public string ManagerName = "Unknown";     public abstract void Load(); } public class RealManager : ManagerBase {     public override void Load()     {         ManagerName = "Manager";     } }

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46

   using System; class Program {     static void Main(string[] args)     {         Employee employee = new Employee(); Console.WriteLine("Employee name: {0}", employee.EmployeeName);         Console.WriteLine("Manager name : {0}", employee.Manager.ManagerName); Console.WriteLine("Loading manager..");         employee.Manager.Load();         Console.WriteLine("Manager name: {0}", employee.Manager.ManagerName);         Console.ReadKey();     } } public class Employee {     public string EmployeeName = "Employee";     public Manager Manager = new Manager(); } public class Manager : ManagerBase {     private RealManager m_RealSubject;     public override void Load()     {         if (m_RealSubject == null)         {             m_RealSubject = new RealManager();         }         m_RealSubject.Load();         ManagerName = m_RealSubject.ManagerName;     } } public abstract class ManagerBase {     public string ManagerName = "Unknown";     public abstract void Load(); } public class RealManager : ManagerBase {     public override void Load()     {         ManagerName = "Manager";     } }

   
   

In the simplified real world example you have two related entities Employee and Manager. Imagine both entities should be retrieved from the database. Image also that the manager has a manager, which has a manager, which has a … Before you know it, you have retreived the whole company from the database. That is not what you want, you only want to access some of the attributes of the employee and not the manager. If you want to access the employee’s manager, you have to load it explicitly.

This post is part of my series on the foundational design patterns in C#. In this series we explore the ancient design patterns and their use in real-world programming situations of today. In these series of posts we explore each pattern and look at simplified real-world C# code that implements the pattern.

Anyone serious about learning object-oriented design and development should study design patterns. In fact, if you didn’t use design patterns before in your software designs or in your code, you should study them right here and right now! And start using them, of course. Use them a lot.

The problem is that you can find information about design patterns almost everywhere on the internet. Examples can be found in almost any language, including Java and C#. Instead of looking everywhere, from now on you can find all the information here. To be honest: this is a memory dump.

In short, design patterns describe solutions to common object oriented design problems. The Gang of Four (GoF) patterns are generally considered the foundation for all other patterns. You can call them the mother of all patterns.

The GoF patterns are generally categorized in three groups: Creational, Structural, and Behavioral Patterns. Other categorizations are possible also, but for now we stick to the original categorization.

Creational Patterns

• Abstract Factory provides a way to encapsulate a group of individual factories that have a common theme;
• Builder separates the construction of complex objects from their representation so the construction process can be used to create differen representations;
• Factory Method defines an interface to use to create an object, but lets subclasses decide which class to instantiate;
• Prototype provides a way to dynamically select which object to instantiate, an to return a clone of a prototypical object;
• Singleton provides a way to ensure that a class provides one instance of itself, and to provide a global point of access;

Structural Patterns

• Adapter provides a way to use an object whose interface is different form the one expected, without having to modify client nor object;
• Bridge decouples an abstraction from its implementation so both can vary independently;
• Composite represents whole-part hierarchies (tree structures) so that individual objects and compositions of objects can be treatet uniformly;
• Facade provides a unified interface to a set of interfaces in a subsystem;
• Decorator gives you a way to extend the behavior of an object, and you can also dynamically compose an object’s behavior without the need to create new subclasses;
• Flyweight uses sharing to support large numbers of fine-grained objects more efficiently and reduce resource usage;
• Proxy provides a way to use a surrogate or placeholder to another object in order to control access to it.

Behavioral Patterns

• Chain of Responsibility promotes loose coupling between sender of a request and its receiver by giving more than one object an opportunity to handle the request;
• Command encapsulates an action/request as an object;
• Interpreter provides a way to handle requests in a representation of the grammar of a language;
• Iterator provides a way to access the elements of an aggregate object sequentially without having to know the underlying representation;
• Mediator encapsulates how a set of objects interact;
• Memento provides a way to capture and externalize an object’s internal state so that it can be restored at a later time;
• Observer defines a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically;
• State provides a mechanism to allow an object to alter its behavior in response to internal state changes;
• Strategy provides a means to dynamically swap algorithms;
• Template allows you to define a skeleton of an algorithm in an operation and defer some steps to subclasses;
• Visitor uses an external class to act on data in other classes;

These are the classic pattern(s). If you want to acquire deep understanding of  design patterns,  you not only have to study design patterns thoroughly but you also have to implement them one-by-one in your favorite coding language.