Day 1
Why Patterns
This chapter discusses the reasons why you should study design patterns. Design patterns offer the ability to reuse solutions not just code. By reusing already established designs, you get a head start on problems and avoid gotchas; you benefit by learning from the experience of others; you do not have to reinvent solutions for commonly recurring problems.
Design patterns establish a common terminology allowing developers to use a common vocabulary and share a common viewpoint of the problem. Design patterns provide a common point of reference during the analysis and design phase of a project.
The course will use UML as a means to communicate pattern intent, and this chapter will introduce key UML concepts.
Singleton
Some solutions require the use of a single object instance across the whole solution, for example naming services, cached objects. This chapter will introduce the singleton pattern as a solution, along with variations for thread safety, and other varieties of single instance based on thread affinity.
Creation Patterns
There are occasions when you want to decouple the knowledge of which type to create from the client code. This is essential for effective unit testing. There are a variety of creation pattern that will allow you do this by encapsulating the necessary knowledge of how to create the object thus allowing the actual implementation used to vary. In this chapter we will look at the Factory, Builder and Prototype patterns.
Day 2
Observer
The ability to notify interested entities of changes to an object state is a fundamental requirement of most Object oriented solutions. There are many ways to do this but there is a danger that we will build a tightly coupled system, we prefer to build a loosely coupled system. The typical way of implementing the observer pattern is to use interfaces, but we will show that delegates and events are a far more flexible and efficient way of implementing the pattern on the .NET framework.
Strategy and Template
What we can be 100% sure of with software is that constantly needs to evolve. What we also know is every time we change existing working code there is a risk that we will break it. What we need is an approach that will allow the software to evolve without having to modify existing working code. The strategy and template patterns allow us to build solutions that can evolve without the risk of effecting existing well tested code.
Iterator, Composite and Visitor
There is often a need to access every object inside an object hierarchy, user interface control objects, documents, business entities, file systems. etc. The iterator pattern provides a standard means to achieve this, .NET provides a standard implementation of this; further the C# language simplifies the implementation further through language extensions. The visitor pattern gives us the ability to layer behavior onto the hierarchy without the need to change the underlying implementation of the hierarchy. Continuing the theme closed for modification open for extension.
Day 3
Decorator
One of the key design pattern goals is to write code that is closed for modification and open to extension, this pattern will show that an object's behavior and responsibilities can be extended at runtime, as opposed to design time using inheritance. This will allow us to combine a variety of behaviors far more efficiently that normal inheritance. Examples of decorators in the framework are BufferedStream, SynchronizationWrappers, and XmlValidatingReaders.
Command
The command pattern allows us to encapsulate invocation, allowing the invoker to be decoupled from the client and the recipient, this enables us to build a variety of different invokers to deliver custom thread pooling, and invocation logging to build fault tolerant solutions. We continue to extend the command pattern to not only encapsulate forward invocation but also undo invocation, allowing us to build a complex undo sequence through a series of simple undo commands.
State
In many cases object behavior will depend on the state an object is in, we typically model the internals of objects through the use of finite state machine. This pattern provides a means to map a finite state machine into a series of classes where each class represents a different state, and thus providing different behaviors. This approach allows us to add new states and transitions without effecting existing code, continuing the theme closed for modification, open for extension.
Day 4
Proxy, Interceptor
The proxy pattern manages the invocation of an object, by hiding the true nature of the location and invocation mechanism of the object, typically used to make remote method calls. Proxies have a host of uses from the conventional RPC style to more elaborate uses such as virtual proxies, security proxies and caching proxies. Proxies can be built manually, using the CLR or using third party libraries that can be used to automate the process. We will look at all three approaches to building effective proxies.
ORM's and Repository Pattern
Object Relational mappers provide a good separation of business logic from persistence logic; however using a given ORM often leads to code being coupled to a particular ORM. This has two effects, one making it hard to test application logic without a physical database, two results in your code being coupled to a given provider. The Repository pattern creates an anti-corruption layer to allow you to take advantage of an ORM whilst still maintaining your ability to test, and change your choice of ORM simply and cleanly. Finally we round of this module looking at Unit Of Work pattern to aggregate many repositories and provide centralized change tracking across all the repositories. In this chapter we will use MS Entity Framework (EF) as an ORM, evolving code from using EF directly to utilizing the patterns thus taking full advantage of the ORM whilst keeping our code flexible and testable.
MVC
The Model/View/Controller design pattern provides guidance on how to separate the various component parts of a UI application. Building UI applications without clear separation often leads to the inability to unit test the application, as a tester is required to drive a user interface. In this chapter we will show how to separate the various concerns to build a testable Web UI application.
