Design patterns: when, why and which one?
Design patterns, as used in this article referes to the use of templates to design software applications. These templates are common recurring themes of structure that seem to crop up in varied situations. For example, every application at some point needs to create objects (or things, if you are not object-oriented). One pattern that can be used to represent this behavior is called the factory pattern. This pattern is based on a manufacturing factory metaphor. Thus it stamps out objects of various kinds when requested.An application design can be composed of many different patterns. These patterns are woven together to create a complex design. This is very similar to a process of using lego bricks to create your structure of choice. Thus to create a house with your lego bricks, you would use the arch bricks, the roof bricks, the garage door brick, a few plain vanilla bricks to create walls, a door brick and perhaps a few window bricks. Each of these brick types corresponds to a design pattern that is used repeatedly.
Like a musician, the skill of a software archtect is based not only, on the understanding, that individual has of the standard design patterns available but also on the ability to deviate from those patterns when necessary to achieve an optimal design. Every pattern has inherent advantages and disadvantages. Choosing a pattern involves a decision that compares the trade-offs for a particular situation. A decision driven as much by experience as raw knoowledge. Some of the factors an architect must weigh in making this trade-off are cost, aesthetics, maintanability, functionality and performance.
What makes for a good pattern
- Abstraction, definition and nomenclature
- Natural interaction with other patterns
- Easily extensible or adaptable
What patterns are not
- Patterns are not libraries
- A pattern is not a single class
- A solution to all your architectural problems
Let us take an example to elucidate the above points a little better. In designing an application, that supports an order acceptance and processing process, for a large multi-national retailer; a need was expressed to maintain synchronization between databases across multiple continents. The applications would be required to access and update these databases while ensuring that data integrity is amintained across them. The volume of transactions that had to be supported peaked at approximately 10,000 about once a year.
To meet the above requirements, the solution used asynchronous messaging to provide fire and forget capabilities. A command pattern was used to generate action as from the system is response to a user request. The responsibility was delegated to one of a number of proxies that acted on behalf of supporting systems. The messaging system was integrated with multiple databases via adapters that performed the necessary conversions of formats and datatypes. Inputs from auxiliary systems generated responses from listeners, which needed to be notified of changes to the system state.
(c) 2004 Vivek Pinto For more details please visit us at Wonomi TechnologiesBibliography:
Design Patterns - by Eric Gamma, et al
posted by vivek pinto @ 2:58 PM
0 comments
