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.

Design Principles And Patterns

I am dedicating this area to talk about anything related to software. My First series of posts will be related to software Architecture and Patterns.

This initial post will outline some basics principals that an architect should always have in the back of his/her mind. Then I will talk a bit about some OOD principles. As we talk about these topics, patterns, idioms and other subjects will come into play.

Bad Smells in the Code

There are certain things, “smells”, that I look for when doing code review. These smells separate good code from bad code.

• Rigid, therefore fragile. A rigid code is basically the one that is resistant to change. This is measured in terms of regression. Ex. You fix a bug here and it breaks some place else. This kind of code (with hidden dependencies) is fragile.
•  Easier to use than reuse. If you try to reuse the code in another project …. forget it !!!. The code has so many dependencies that it just does not work.
• Easier to Work around than to fix. Many times you are facing this decision: Fix a problem in a elegant way, but lots of work, or hack it. When a hack is faster to apply than the real solution, engineers tend (due to schedule pressure or pure laziness) to take the easy road. Dino Esposito and Andrea Saltarelo mention in their book (Microsoft .NET Architecting Application for enterprise). “This aspect of design –that invites or accommodate workarounds more or less than fixes – is often referred as to viscosity”. High viscosity means the software resists to changes.

Structured Design

• From Spaghetti to Lasagna code. I think this phrase says everything. Favor layered software it is reusable and modular.
• Cohesion. Measures how strongly-related and focused the various responsibilities of a software module are. Target high cohesion modules they favor maintenance and reusability because they tend to have no dependencies. read Ward Cunningham (http://c2.com/cgi/wiki?CouplingAndCohesion). “He says that two modules , A and B, are cohesive when a change to A has no repercussion for B so that both modules can add new value to the system”.
• Coupling. It measures the level of dependency existing between two software modules, such as classes, functions and libraries. Favor low coupling.

Advanced Principles

• The Open/Close Principle. The idea is simple… produce code that can survive changes. So we need some mechanism that allow us to create new code without breaking existing code that works. Basically “A module should be open for extension but closed for modification”. Every time a change is required, you enhance the behavior of the class by adding new code and never touching existing old code that works.
• Liskov’s Substitution Principle. That is an interesting one. Basically it states that “Subclasses should be substitutable for their base class”.

I am getting tired of writing so on the next article I will continue the discussion on software design. I will concentrate on Design patterns and code testability.

Cheers