Design Patterns

We software professionals owe design patterns to an architect – Christopher Alexander. In 1970s, Christopher Alexander developed a pattern language with the purpose of letting individuals express their innate sense of design through a sort of informal grammar.

So what is a pattern? A design pattern is a known well-established core solution applicable to a family of concrete problems that might show up during implementation.  A design pattern is a core solution and, as such, it might need adaption to a specific context.

Using design patterns does not make your solution more valuable because at the end of the day the only thing that matters is that the application works and meet the requirements.

Patterns might be an end when you refactor according to them, and they might be a means when you face a problem that is clearly resolved by a particular pattern. Patterns are not an added value for your solution, but they are valuable for you as an architect or a developer looking for a solution.

Patterns vs. Idioms

Software patterns indicates well established solutions to recurring design problems. Sometimes specific features of a given programming language can help significantly in quickly and elegantly solving recurring problem. When a solution is hard coded on the language or implemented our of the box it is called an idiom.  

As far as the .NET is concerned, a set of idiomatic design rules exists under the name of Framework Design Guidelines. you access them online: http://msdn.microsot.com/en-us/library/ms229042.aspx you can also find useful information at http://blogs.msdn.com/kcwalina

Here are some examples:

• Idiomatic Design: Strucutres or Classes? – The guidelione suggests that you always use a class unless the footprint of the type is below 16 bytes and the type is immutable.
• Idiomatic Design: Do not use List<T> in public signatures? One of the reasons for this guideline is that List<T> is a rather bloated type with many members that are not relevant in many scenarios. This means that List<T> has low cohesion and to some extent violates the Single Responsibility Principle. Another reason is that the class is unsealed but not specifically designed to be extended. It is therefore recommended the you use IList<T> instead, or derived interfaces, in public signatures. Alternatively, use custom classes the directly implement IList<T>.

Dependency Injection

DIP has been the buzzword lately in my group as has been widely used as a pattern. DIP states that higher level modules should depend on abstractions rather than on concrete implementation of functionalities. Inversion of Control is an application of DIP that refers to situations where generic code controls the execution of more specific code and external components.

IOC resemble the template method pattern (http://en.wikipedia.org/wiki/Template_method_pattern) where you have a method whose code is filled with one or more stubs. The functionality of each stub is provided by external components invoked through an abstract interface. Replacing any external components does not affect the high-level method. Of course IOC is not applied to an specific method but throughout the code.

Today IOC/DI is often associated with special frameworks that offers a number of rather advanced features.

Here are some examples

Framework	More Information
Castle Windsor	http://www.castleproject.org/container/index.html
Ninject	http://www.ninject.org/
Spring .NET	http://www.springframework.net/
StructureMap	http://structuremap.sourceforge.net/Default.htm
Unity	http://www.codeplex.com/unity

Those are very interesting frameworks to take a look at it and get some ideas. I am personally familiar with Unity and Spring.

All IOC frameworks are built around container object that, bould to some configuration information resolve dependencies. The caller code instantiates the container and passes the desired interface as an argument. In response, the IOC/DI framework returns a concrete object that implements that interface.

I will spend some time on the next post talking about Unity and back to our pattern discussion.