[Tutorial] Common Design Patterns in C# 4.0 Part8: Bridge Pattern

Pattern Name:
Bridge Pattern

Short Description:
Separate implementation and object interfaces

Usage: 
Sometimes used, useful to decouple an abstraction from its implementation and to be able to modify them independently.

Note that the Bridge pattern has nearly the same structure as the Adapter Pattern. But it is used when designing new systems instead of the Adapter pattern which is used in already existing systems.

Complexity:
1 / 5

UML Class Diagram:

Explanation:

• The abstract Repository class defines the interface that all inheriting refined Repository classes will use for object management purposes.
• Note that the operations within the Repository classes define high-level operations.

• The refined Repositories extend the basic functionalities and implement the execution code that uses the implementation classes. They should contain specializations which only apply to specific Repositories. 

• The abstract DataObject class defines the interfaces of the implementation classes. Note that the abstract Repository and the abstract DataObject classes can have completely different interfaces.
• The concrete DataObject implementations contain the code that executes all the low-level operations.
• Note that the methods within the Repository class could also call multiple methods in the implementation classes (1 to * relationship).

• In the last step we add some code to test the software design and the Bridge implementation.

• When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.

Source Code:
http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part8: Bridge Pattern

[Tutorial] Common Design Patterns in C# 4.0 Part7: Adapter Pattern

Pattern Name: 
Adapter Pattern

Short Description:
Match interfaces of classes with different interfaces

Usage:
Often used and easy to implement, useful if classes need to work together that have incompatible existing interfaces.

Complexity: 
1 / 5

UML Class Diagram:

Explanation:

• The TradingDataImporter class acts as a client using classes with an existing Connector interface.

• The abstract Adapter class defines the interface that the client class knows and that it can work with.
• The concrete Adapter classes convert the interface of the incompatible classes into an interface the client expects. They make different existing interfaces work together.

• Here are some examples of different adaptee classes that implement different interfaces. However, the client expects a generic interface that they currently don’t provide. That is why they get wrapped by the concrete adapter classes to make them compatible with the client.

• In the last step we add some code to test the software design and the Adapter implementation.

• When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.

Source Code:

http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part7: Adapter Pattern

[Tutorial] Common Design Patterns in C# 4.0 Part6: Singleton Pattern

Pattern Name:
Singleton Pattern

Short Description:
Class with only one single possible instance

Usage: 
Often used for objects that need to provide global access with the constraint of only one single instance in the application

Complexity:
1 / 5

UML Class Diagram:

Explanation:

• There are multiple ways of implementing the Singleton Pattern in C#. I am going to explain the most efficient approaches that also provide thread safety.
• Note that in the first example the default constructor is defined as private so that it is not possible to instantiate the object from the outside. The class is also marked as sealed which means that inheritance is not allowed for it.
• The internally instantiated object is stored in a private variable that is marked as static. The public static property GetInstance is used to allow access to this object. It contains the business logic that assures that only a single instance can ever exist.
• To achieve this behavior a lock strategy is used to assure that only a single thread is allowed to do the null check and create a new instance if it does not already exist.
• A test function DisplayConfiguration() was added to be able to verify the class design.

• Note that in the second example the default constructor is also defined as private so that it is not possible to instantiate the object from the outside. The class is also marked as sealed which means that inheritance is not allowed for it.
• This time a private nested class is used to provide access to the instance that must only exist once in the application.
• This nested class has a static default constructor and an internal static read-only instance of the object. Only the container class has access to the instance which will due to the software design (auto-instantiated and marked as read-only) only exist once.
• A test function DisplayRules() was added to be able to verify the class design.
• I recommend using this example as your default approach for your Singleton implementations since there is no locking in it which makes it more efficient in terms of performance.

• In the last step we add some code to test the software design and the Singleton implementation.

• When running the example you can see that everything is working as expected (it is however not as simple to test that there really is just one single instance, you just have to believe in the correct software design).

Source Code:

http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part6: Singleton Pattern

[Tutorial] Common Design Patterns in C# 4.0 Part5: Prototype Pattern

Pattern Name:
Prototype Pattern

Short Description:
Clone or copy initialized instances

Usage: 
Easy pattern, usage depends on the preferred software design, provides an alternative to the other creational patterns that are mainly based on external classes for creation

Complexity:
1 / 5

UML Class Diagram:

Explanation:

• The abstract prototype class defines the interface that contains a clone method for cloning itself.

• The inherited classes implement the clone function. Note that C# provides two different ways of cloning an object: by shallow copy (only top level objects) or by deep copy (all objects). 
• You could also manually create a new object and set its values with the values of the original object but since C# already implements everything necessary I advise using that.

• The client class does not create new objects itself. Instead it asks the objects to clone themselves when needed. The cloned objects are perfect copies and contain all values of the original objects depending on the shallow or deep copy approach (see above).

• You may also use the ICloneable interface that already exists in C#

• In the last step we add some code to test the software design and the Prototype implementation.

• When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.

Source Code:
http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part5: Prototype Pattern

[Tutorial] Common Design Patterns in C# 4.0 Part4: Factory Method Pattern

Pattern Name:
Factory Method

Short Description: 
Create instances of derived classes

Usage:
Frequently used, fairly easy to implement and useful for centralizing object lifetime management and avoiding object creation code duplication

Complexity:
1 / 5

UML Class Diagram:

Explanation:

• The abstract creator implements a factory method that returns an objects. It also contains a method for testing purposes that serves to validate the design.
• Each concrete creator overrides the abstract factory method and returns a specific object concerning on the context.
• In this example the factory method is used internally to set a property but it could also be used in an external context for creating objects when needed.

• The abstract class defines the interface and class structure for all objects that get build by the specific concrete creators via their factory methods.

• There is also the possibility to create a C# specific solution that uses generics which also results in a valid factory method.

• In the last step we add some code to test the software design and the Factory Method implementation in the language agnostic and in the C# specific versions.

• When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.

Source Code:
http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part4: Factory Method Pattern

[Tutorial] Common Design Patterns in C# 4.0 Part3: Builder Pattern

Pattern Name: 
Builder Pattern

Short Description:
Separate representation and  object construction

Usage: 
Rarely used, only useful if complex objects consisting of multiple parts need to be constructed (composite objects for example)

Complexity:
1 / 5

UML Class Diagram:

Explanation:

• The director (ComputerShop) implements a method that is responsible for the sequence of steps of an object creation process. It takes an abstract builder class as input parameter and delegates the real creation to it.
• The abstract builder class defines the interface that all inheriting concrete builders will use for object creation.

• The concrete builder implementations contain the parts that are assembled and that build the objects.

• The final object contains all different parts that get assembled by the concrete builder classes. Those may differ from each other depending on the implementations.
• A method was added that prints out the characteristics of the different parts to be able to validate the design.

• In the last step we add some code to test the software design and the Builder implementation.

• When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.

Source Code:
http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part3: Builder Pattern

[Tutorial] Common Design Patterns in C# 4.0 Part2: Abstract Factory Pattern

Pattern Name:
Abstract Factory Pattern

Short Description:
Create instances of classes belonging to different families

Usage:
Very frequently  used and very useful

Complexity:
1 / 5

UML Class Diagram:

Explanation:

• The abstract factory class defines the abstract methods that have to be implemented by concrete factory classes. It serves as interface and contract definition.
• The concrete factory classes contain the real implementation that define which classes are created during run-time.
• Note that the methods return values are also defined by abstract classes, this allows a high flexibility and independence, leading to methods that must only be implemented once.
• The returned classes are however specific to each concrete factory class (you will see their implementation below).

• Here you see the abstract classes that are used during the creation process (a method was added that serves to prove the validity of the design).
• Based on the abstract classes some real example implementation are created, those will be instantiated during run-time, depending on the concrete factory that creates them.

• When implementing the associations between the Driver class, the abstract factory class and the abstract classes you may either use the common language agnostic approach using only private members (which is the most memory efficient one).

• Or you may use the C# language specific approach where everything is wrapped using private properties. This allows adding logic when accessing or changing the private members but might be a little overkill.

• You may also use another C# language specific solution that uses generic classes to create objects and that is also a valid implementation for the abstract factory pattern.

• In the last step we add some code to test the software design and the Abstract Factory implementation.

• When running the example you can see that everything is working as expected and that the correct classes are instantiated during runtime.

Source Code:
http://csharpdesignpatterns.codeplex.com/

[Tutorial] Common Design Patterns in C# 4.0
Part2: Abstract Factory Pattern

[Tutorial] Common Design Patterns in C# 4.0 Part1: Introduction Gang of Four Design Patterns

Design Patterns provide standardized and efficient solutions to software design and programming problems that are re-usable in your code. Software Architects and developers use them to build high quality robust applications.

However, you have to take care to select the right pattern for the right problem. If you need to modify the initial pattern too much, this may indicate that it is not adapted to your needs and may in the worst case lead to unmaintainable, complex and inefficient code. The opposite of what you intend when using Design Patterns !!

You may also create your own custom Design Patterns. Whenever you come up with a certain solution that is reusable in a vast majority of your projects, you may decide to abstract a design pattern out of it. Then you may create your own library of patterns and share them within your whole company, thus creating standards and ameliorating maintainability.

In this series of blog posts I am going to show you how to use the well known Gang of Four (GoF) Design Patterns in C# 4.0 code. Those patterns will work well in any project that uses C# but especially in WPF, WCF, WinForms, ASP.NET projects.

The GoF Design Patterns are divided into 3 categories : Creational Patterns, Structural Patterns and Behavioral Patterns. In my following blog posts I am going to explain each GoF Design Pattern in detail and will show you examples of how to write good C# 4.0 code that implement those patterns.

Creational Patterns

• Abstract Factory: Create instances of classes belonging to different families
  
  
• Builder: Separate representation and  object construction
  
  
• Factory Method: Create instances of derived classes
  
  
• Prototype: Clone or copy initialized instances
  
  
• Singleton: Class with only one single possible instance

Structural Patterns

• Adapter: Match interfaces of classes with different interfaces
  
  
• Bridge: Separate implementation and object interfaces
  
  
• Composite: Simple and composite objects tree
  
  
• Decorator: Dynamically add responsibilities to objects 
  
  
• Facade: Class that represents subclasses and subsystems
  
  
• Flyweight: Minimize memory usage by sharing as much data as possible with similar objects
  
  
• Proxy: Object that represents another object

Behavioral Patterns

• Chain of Responsibility: Pass requests between command and processing objects within a chain of objects
  
  
• Command: Encapsulate a method call as an object containing all necessary information
  
  
• Interpreter: Include language elements and evaluate sentences in a given language
  
  
• Iterator: Give sequential access to elements in a collection
  
  
• Mediator: Encapsulates and simplifies communication between objects
  
  
• Memento: Undo modifications and restore an object to its initial state
  
  
• Observer: Notify dependent objects of state changes
  
  
• State:Change object behavior depending on its state
  
  
• Strategy: Encapsulate algorithms within a class and make them interchangeable
  
  
• Template Method: Define an algorithm skeleton and delegate algorithm steps to subclasses so that they may be overridden
  
  
• Visitor:  Add new operations to classes without modifying them

There are also many other types of pattern such as: Parallel Patterns, SOA Patterns, Enterprise Architecture Patterns, etc… So if you work in the respective area don’t hesitate to look up patterns that may help you to be more efficient and build better applications.

[Tutorial] Common Design Patterns in C# 4.0
Part1: Introduction Gang of Four Design Patterns