[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

[C# - PRISM 4.0] Building highly flexible and modular applications

I already showed you some time ago how to create good and efficient code by using the S.O.L.I.D. design principles. This time I would like to focus on PRISM 4.0 and its features.

The goal for good software architecture is always the same : produce code that is flexible, highly modular, easy to maintain, simple to extend and overall as independent as possible.

This can very well be achieved by applying best practices and having good programming skills but it will get even more powerful when using existing frameworks that already contain all foundations and have all necessary patterns in place. One of the most mature and advanced frameworks is PRISM 4.0 (patterns & practices) which will allow you to be much more productive when correctly used.

Prism 4.0 provides guidance to help easily design and build rich, flexible, and easy-to-maintain applications. It works with Microsoft .NET Framework 4.0 and Silverlight 4, the latest technologies currently available.

It especially works well with the following project types:

• Silverlight Applications
• WPF Applications
• Windows Phone 7 Applications

Furthermore it support MVVM and MEF and is open for usage with different dependency injection containers (by default it uses Unity). It is build from ground up using Design Patterns that favor separation of concerns and loose coupling which allow Composite Applications.

The goal is to partition applications into a number of discrete, loosely coupled, semi-independent components and modules that can be individually developed, tested, and deployed by different subteams.

PRISM 4.0 helps to achieve a very clean separation between UI and Business Logic. Efficient reuse of existing functionalities and a clean separation of concerns between horizontal capabilities (logs, custom authentication, etc…) can be very quickly attained. When using MEF it is also extremely easy to create modular applications where functionalities can be dynamically added (even during runtime).

The existing classes and functionalities really help very much and provide a robust basis on which you can build on. The concentration can really be on the business functionalities and not the surrounding shell.

Needless to say that you will have to familiarize yourself with the framework and look into examples on how to use it correctly. You should also decide if you really need to be so modular and if you will have an added value because for monolithic and simple applications it might not be advisable to have such an approach. And surely you could also build everything yourself but you might take a look and evaluate if it is usable in your context. Did I mention that it is free ? So don’t hesitate and look for yourself and try it out, it might help you to build better applications quicker, with less stress and for less money !

[C# - PRISM 4.0] Building highly flexible and modular applications