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.
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
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
- LAB: Avoiding the String-based programming anti-pattern
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
So how can you become a better developer? One of the best ways is by learning design patterns. Design Patterns
provide reusable solutions to solve common software design problems. In this training we identify software design
problems and see how to address these using the best suited Design Pattern.
This course is intended for experienced programmers who are very familiar with VB.NET or C#
and have a working experience with the .NET Framework.