Dissection of an Application Framework - Design Patterns
(Page 7 of 7 )
As you are architecting and developing the application framework, you will often run into design challenges on recurring scenarios, such as how to improve handling of changes to the process flow and how to improve application-specific customization. Design patterns, which describe the solution to common software development problems, can assist you in solving some of these common problems in developing an application framework. Many commonly used design patterns are documented in the classic book Design Patterns: Elements of Reusable Object-Oriented Software, by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, the “gang of four” (GOF). Some design patterns are especially useful in application framework development. The following list describes some of these patterns and the problems they can solve:
Strategy: a design that handles the variation of algorithms in the application. It allows the developer to customize the framework by “plug and play”-ing different application-specific algorithms.
Bridge: a design that decouples the abstraction and implementation in the application. It allows developers to provide different implementations for part of the application without affecting other parts of the application.
Decorator: a design that provides a layer approach in processing data. It allows developers to easily assemble multiple components to process data.
Observer: a design that provides a publish–subscribe communication model. It allows developers to disperse information easily to multiple objects.
Mediator: a design that keeps objects from referring to each other explicitly. It allows developers to create loosely coupled communication between different objects.
Template method: a design that provides the skeleton of the algorithm it operates. It allows developers to define process flow and coordination logic without having to define how the algorithm is implemented.
Visitor: a design that lets you define a new operation without changing the existing ones. It allows developers to decouple an operation from the coordination logic that is constantly changing.
Singleton: a design that ensures that only one instance of the class is created. It allows developers to have better control of the creation of the object.
Abstract factory: a design that provides an interface for creating families of objects without specifying their concrete classes. It allows developers to reduce the reference to concrete classes throughout the application, and hence reduce the amount of code changed when the concrete classes change.
For the rest of the book, we will look at how these design patterns can help us develop our application framework and how these patterns are implemented in .NET.
Summary In this chapter, you have learned about processes and techniques of application framework development. We first looked at the different layers that make up the application framework and how each layer is related to the others. Then we looked at the framework development process, which involves analysis, design, development, and stabilization stages in an iterative fashion and specific tasks involved in each of these stages. Following that, you learned about the several approaches in framework development, such as white-box, black-box, and gray-box frameworks. We also looked at some key framework development techniques through discussion of common-spot, hot-spot, and design patterns. For the rest of book, we will consider how to actually design and implement an application framework through examples. We will use a sample framework as reference to show you how you can develop your application framework using .NET technology and design patterns.
 This chapter is from Developing Application Frameworks in .NET by Xin Chen (Apress, 2004, ISBN: 1590592883). Check it out at your favorite bookstore today. Buy this book now.
|
| DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware. |
