1. Introduction
In the previous parts of the article I showed you the first two groups of patterns used in the Composite Application Library (CAL) – Composite User Interface patterns and Modularity patterns. In the final part I will show you the third group – Testability patterns.
As a whole the patterns used in CAL can be separated in three main groups:
- Composite User Interface patterns (part 1)
- 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
3. Testability patterns
3.1. Inversion of control
Maybe that pattern must be examined before the Service Locator and the Dependency Injection patterns, but since it is part of the last group of patterns I decided to show you the individual patterns in a street succession. Let’s examine the problem we had at the Service Locator and the Dependency Injection patterns again.
The client class has dependencies on services or components whose concrete type is specified at design time. In this example the ClientClass has dependencies on Service1, Service2 and Service3. The problems are well known. We need a solution which will cope with these problems. In a few words, the solution is to delegate the functions of selecting a concrete implementation type for the classes’ dependencies to an external component.
The pattern can be implemented in several ways. The most famous implementations are the Dependency Injection pattern and the Service Locator pattern which I showed you in the previous part of the article.
The both patterns are specialized versions of this pattern that sketch different implementations. I will repeat the advantages again:
- It decouples your classes from their dependencies, so these dependencies can be modified or replaced with minimal changes to your classes.
- Your classes depend on classes whose concrete implementation is unknown at compile time.
- You are able to test your classes in isolation.
- Your classes are not responsible for locating and managing the dependencies.
The biggest problems at that pattern are that:
- It adds more complexity to the source code.
- It needs a mechanism that provides the dependencies that are required by the object that is being initialized to be implemented.
3.2. Separated presentation
Separated presentation patterns allow you to separate out the visual portions of your application from the business and presentation layers. This is very important due to a number of reasons. First, having a clean separation between your application’s UI and the application logic means that you can do your unit test independently of the user interface. Another key benefit is that the pattern allows the developer to focus on the application logic, while the designer can focus on the visual aspects of the program. Also using a separated presentation pattern makes the application easier for maintenance and easier to understand it. It also provides opportunities for code re-use (which is in fact the heart of the object oriented programming). There are a number of design patterns that support a separated presentation approach. Almost all of these patterns separate out the user interface and application logic into three components: a component for the user interface, a component for the presentation logic, and a component for the application logic. There are many variations between the patterns because of the specific ways in which these three components are implemented and interact with each other.
All of the patterns are well – known of the world. There are tones of information about them, so I will just count them and will not dive into details.
- Presenter – First – in that pattern the presenter is created first and then hooked up to a suitable view and a model.
- View – First Composition – here the view is created first and then hooked up to a suitable presenter and a model.
- Supervising presenter – a variation of the Model – View – Presenter (MVP) pattern.
- Presentation model – a variation of the Model – View – Presenter (MVP) patterns.
- Model – View – Controller (MVC) – maybe the most famous composite pattern. You can see a detail explanation as well as a practical realization here.
- Model – View – Presenter (MVP) – a derivation of the MVC patterns. Also extremely popular in the programming world. You can see a brief overview of the pattern as well as an interesting practical example here.
4. Conclusion
In that series of articles I showed you the most important patterns, practices and approaches which are used in the Composite Application Library. I hope every one of us who will decide to start adopting the Composite Application Library will find this article useful and it will reveal the nature of the CAL. Any feedback is appreciated.
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