1. Introduction
In previous articles I showed how the most famous composite design patterns (Model – View – Controller and Model – View – Presenter) can be used with great success in Silverlight despite of the different programming model in Silverlight. My latest article targets a completely new pattern which has been created especially for WPF, but it is also very suitable for Silverlight applications. Today I’ve decided to continue my series of articles with OOP approach and to present you the main design patterns and practices used in the Composite Application Library (CAL). The Composite Application Library (also known as Prism) is used to create composite WPF/Silverlight applications. The main purpose of the article is not to show you the components of the CAL or any step by step tutorial, but to show the main object oriented techniques which lied in the heart of the library. I think anyone who wants to start building composite applications, evaluating and adopting the CAL should be familiar with these software design patterns. This article offers you a great opportunity to do that.
As a whole the patterns used in CAL can be separated in three main groups:
- Composite User Interface patterns
- Composite
- Composite View
- Command
- Adapter
- Modularity patterns (part 2)
- Separated interface and Plug In
- Service Locator
- Dependency Injection
- Event Aggregator
- Façade
- Registry
- Testability patterns (part 3)
- Inversion of control
- Separated presentation
Next three articles will cover all these patterns in great details. Today I will start with the first group of patterns – Composite User Interface patterns. So let’s our overview begin.
As the name of the library suggests in the heart of a composite application laid the Composite pattern. Very often when we create new software systems each component may be either a collection of objects or an individual object. The Composite pattern is used to satisfy both of the cases. You can use that pattern to build whole hierarchies or to construct data representations of trees. The most widespread definition for the Composite pattern is: compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly. In summary, the Composite pattern allows you to create a class hierarchy of simple objects and more complex composite objects so they appear to be the same to the client program. A simple diagram of the composite pattern can be seen on the next figure.
In the .NET framework there are a lot of examples for composites. For example we use the Tree Node object to populate the TreeView and in fact this is just a simple composite pattern. Similarly, tool strips are containers; each one may contain any number of other containers. In Silverlight and WPF the Composite pattern is even further used.
If you are familiar with the Composite pattern you will find the Composite View very similar to it. The Composite View pattern is closely related to the Composite pattern. It allows us to organize View objects into a nested tree structure or into a composite view. This is the heart of a composite application. A simple example for composition may be seen on the next figure.
As you can see the main view of the application may define a navigation area and content area to host child views dynamically at run time.
3.3. Command
The Command is one of the most famous patterns. It allows you to encapsulate a request (action) as an object, so you can parameterize clients with different requests. The benefit is a decoupling of the invoker of the command and the handlers of the command. The client doesn’t know anything about the action that will be performed (the client knows only the public interface). You can also change the action without affecting the client program. You can see the class diagram for the pattern on the next figure.
This simple structure has an enormous advantage. The invoker doesn’t know what it is doing. Whenever it detects an event, it simply calls Execute() on the command that it is attached to.
One very important characteristic of the CAL is that it allows us to combine multiple ICommand items and to create a CompositeCommand. The CompositeCommand is a command that has multiple child commands. The current association between the invoker and the command on the last diagram is 1:1. But what happens if you want to change the association to 1: many, without having to modify the invoker? Of course you can revert the 1: many relationship to 1:1 by using the Composite. This is possible because every object in the list is treated identically. Of course if you maintain a list of employees, you shouldn’t probably use the Composite pattern, because you wouldn’t be treating all the employees identically. You can see the diagram for the CompositeCommand on the next figure.
3.4. Adapter
As the name of the pattern suggests, the Adapter pattern, adapts the interface of one class to match the interface expected by another class. We use adapters whenever we want unrelated classes to work together in a single program. For example: you have classA which has the desired interface and you want to make it communicate with classB that has a different interface. There are two ways to do that. The first one is to use inheritance. You derive a new class from the nonconforming one and add methods to make the new class match the desired interface. The second one is to use composition. You just include the original class inside the new one (creating a wrapper). Both ways are pretty easy for implementation. You can see the class diagram for the Adapter pattern on the next figure.
In the Composite Application Library, the Adapter pattern is used to adapt regions to the ItemControl, ContentControl or Selector.
4. Conclusion
With this article I started covering the most important patterns, practices and approaches which are used in the Composite Application Library. The first part of the series shows you the first group of patterns – the Composite User Interface patterns. I hope every one of us who will decide to start adopting the Composite Application Library will find this series useful and it will reveal the nature of the CAL. In the next part I will cover all patterns, which are part of the Modularity patterns group.
5. References
http://msdn.microsoft.com/en-us/library/dd139883.aspx
http://codebetter.com/blogs/jeremy.miller/archive/2005/09/13/131897.aspx
http://msdn.microsoft.com/en-us/library/cc304894.aspx
http://www.martinfowler.com/eaaDev/EventAggregator.html
http://msdn.microsoft.com/en-us/library/cc304779.aspx