.NET Best Practices: Architecture & Design Patterns

Introduction to Patterns

One might not believe it, but design patterns do not find their origin in software architecture. Patterns were first described in the 1970s by a real "Bricks and Stones" architect. A pattern is defined as a re-usable solution to a common type of problem, without ever repeating the actual way the solution is implemented. This means that patterns are an ideal learning tool and also ideal for communicating design ideas. Of course there are also anti-patterns, things often used, but actually better to be avoided.

• What is a Pattern?
• The Gang of Four: Erich Gamma, Ralph Johnson, Richard Helm and John Vlissides.
• Different kinds of design patterns: creational, structural and behavioral patterns.
• Patterns everywhere: the difference between implementation, design and architecture patterns...
• When to apply patterns, and when not to.
• Some anti-patterns such as Loosy-Goosy.

Creational patterns

When creating software, you feel yourself continuously creating new objects. Although the basic form of creating new objects is not bad, it can result in design problems or added complexity to the design. Creational patterns will help you deal with object creation that is suitable to the situation.

• Singleton - a.k.a. The Pluto Pattern and how the .NET runtime can help at implementing it
• LAB: Building a Singleton in .NET
• Builders - seperating the construction from the representation
• Factory Method - delegating/hiding the creation of objects to a factory
• Abstract Factory - abstracting the factory to create families of objects
• LAB: Implementing an Abstract Factory

Behavioral patterns

Once your objects are created, they start interacting. When you're not careful, these interactions can quickly start leading into code that is tightly coupled. Behavioral design patterns help identifying common communication patterns between objects and realize these patterns. By correctly applying these patterns, you can increase flexibility in carrying out the interaction between objects.

• Template Method - defer exact parts of an algorithm to inheriting classes, delegates, ...
• LAB: Building a Template Method for a board game
• Strategy - template method without the annoying inheritance
• LAB: Implementing a Builder as a Strategy
• Chain of Responsibility - strategy to go through a chain of strategies
• LAB: Using a Chain of Responsibility to implement a Builder
• State - defer state dependending logic to state classes, state machines, using the Stateless library
• LAB: Implementing a VCR with the State patterns
• Iterator - providing a generic way of navigating through collections, yield is your friend, asynchronously iterating a collection
• Observer - notifying whoever is interested in what you have to say, event vs. delegate
• Mediator - providing two-way communication between objects unaware of one another, correcly implementing INotifyPropertyChanged
• LAB: Avoiding the String-based programming anti-pattern

Structural patterns

Created objects do not tend to stand on their own. No, they start encapsulating other objects trying to create structure in, what otherwise would be a chaotic software environment. Structural patterns help at identifying and setting up relationships between objects.

• Adapter - plugging in different objects into your code that do not fit
• LAB: Building INotifyPropertyChanged as a generic Adapter
• Decorator - altering the behavior of an object without the caller realising it
• LAB: Changing IComparable<T> with a Decorator