In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not 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. Object-oriented design patterns typically show relationships and interactionsbetweenclasses or objects, without specifying the final application classes or objects that are involved. Algorithms are not thought of as design patterns, since they solvecomputationalproblems rather than design problems.
Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
History
Patterns originated as an architectural conceptby Christopher Alexander. In 1987, Kent Beckand Ward Cunningham began experimenting with the idea of applying patterns toprogramming and presented their results at theOOPSLA conference that year. In the following years, Beck, Cunningham and others followed up on this work.
Design patterns gained popularity in computer science after the book Design Patterns: Elements of Reusable Object-Oriented Softwarewas published in 1994 (Gamma et al). That same year, the first Pattern Languages of Programs conference was held and the following year, the Portland Pattern Repositorywas set up for documentation of design patterns. The scope of the term remained a matter of dispute into the next decade.
Uses
Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems and improves code readability for coders and architects familiar with the patterns.
Often, people only understand how to apply certain software design techniques to certain problems. These techniques are difficult to apply to a broader range of problems. Design patterns provide general solutions, documented in a format that doesn't require specifics tied to a particular problem.
Design patterns are composed of several sections (see Documentation). Of particular interest are the Structure, Participants, and Collaboration sections. These sections describe a design motif: a prototypical micro-architecture that developers copy and adapt to their particular designs to solve the recurrent problem described by the design pattern. (A micro-architecture is a set of program constituents (e.g., classes, methods...) and their relationships.) Developers use the design pattern by introducing in their designs this prototypical micro-architecture, which means that micro-architectures in their designs will have structure and organization similar to the chosen design motif.In addition, patterns allow developers to communicate using well-known, well understood names for software interactions. Common design patterns can be improved over time, making them more robust than ad-hoc designs.
Classification
Design patterns can be classified in terms of the underlying problem they solve. Examples of problem-based pattern classifications include:
Documentation
The documentation for a design pattern should contain enough information about the problem that the pattern addresses, the context in which it is used, and the suggested solution.
A commonly used format is the one used by theGang of Four. It contains the following sections:
Pattern Name and Classification: Every pattern should have a descriptive and unique name that helps in identifying and referring to it. Additionally, the pattern should be classified according to a classification such as the one described earlier. This classification helps in identifying the use of the pattern.
Intent: This section should describe the goal behind the pattern and the reason for using it. It resembles the problem part of the pattern.
Also Known As: A pattern could have more than one name. These names should be documented in this section.
Motivation(Forces): This section provides a scenario consisting of a problem and a context in which this pattern can be used. By relating the problem and the context, this section shows when this pattern is used.
Applicability: This section includes situations in which this pattern is usable. It represents the context part of the pattern.
Structure: A graphical representation of the pattern. Class diagrams andInteraction diagrams can be used for this purpose.
Participants: A listing of the classes and objects used in this pattern and their roles in the design.
Collaboration: Describes how classes and objects used in the pattern interact with each other.
Consequences: This section describes the results, side effects, and trade offs caused by using this pattern.
Implementation: This section describes the implementation of the pattern, and represents the solution part of the pattern. It provides the techniques used in implementing this pattern, and suggests ways for this implementation.
Sample Code: An illustration of how this pattern can be used in a programming language
Known Uses: This section includes examples of real usages of this pattern.
Related Patterns: This section includes other patterns that have some relation with this pattern, so that they can be used along with this pattern, or instead of this pattern. It also includes the differences this pattern has with similar patterns.
Just a mind blowing tutorial about RoboGuice tutorials. I need some sample codes. Please provide me!
ReplyDelete