| Software Design Patterns Basics |
|
|
Questions and Answers
|
|
Q: What are Design Patterns?
|
|
A: Patterns are devices that allow programs to share knowledge about their design. In our daily programming, we encounter many problems that have occured, and will occur again. The question we must ask ourself is how we are going to solve it this time. Documenting patterns is one way that you can reuse and possibly share the infomation that you have learned about how it is best to solve a specific program design problem.
In software engineering, a design pattern is a general repeatable solution to a commonly-occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code; it is a description or template for how to solve a problem that can be used in many different situations.
|
|
Brief History of Design Patterns
|
|
The origin of design patterns lies in work done by an architect named Christopher Alexander during the late 1970s. He began by writing two books, A Pattern Language[Alex77] and A Timeless Way of Building [Alex79] which, in addition to giving examples, described his rationalle for documenting patterns.
The pattern movement became very quiet until 1987 when patterns appeared again at an OOPSLA conference. Since then, many papers and presentations have appeared, authored by people such as Grady Booch, Richard Helm, and Erich Gamma, and Kent Beck. From then until 1995, many periodicals, featured articles directly or indirectly relating to patterns. In 1995, Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides published Design Patterns: Elements of Reusable Object-Oriented Software [Gamma95], which has been followed by more articles in trade journals and additional books.
|
|
Types of Design Patterns
|
| Creational Patterns |
| : | Creates an instance of several families of classes |
| : | Separates object construction from its representation |
| : | Creates an instance of several derived classes |
| : | A fully initialized instance to be copied or cloned |
| : | A class of which only a single instance can exist |
|
| Structural Patterns |
| : | Match interfaces of different classes |
| : | Separates an object’s interface from its implementation |
| : | A tree structure of simple and composite objects |
| : | Add responsibilities to objects dynamically |
| : | A single class that represents an entire subsystem |
| : | A fine-grained instance used for efficient sharing |
| : | An object representing another object |
|
| Behavioral Patterns |
| : | A way of passing a request between a chain of objects |
| : | Encapsulate a command request as an object |
| : | A way to include language elements in a program |
| : | Sequentially access the elements of a collection |
| : | Defines simplified communication between classes |
| : | Capture and restore an object's internal state |
| : | A way of notifying change to a number of classes |
| : | Alter an object's behavior when its state changes |
| : | Encapsulates an algorithm inside a class |
| : | Defer the exact steps of an algorithm to a subclass |
| : | Defines a new operation to a class without change |
|
|
|
Comments/Feedback:
Please login to participate |
OneInfoPlace server is currently busy. Please try later. Sorry for the inconvenience |
