In software engineering, a design pattern is a general reusable 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 interactions between classes or objects, without specifying the final application classes or objects that are involved.
Design patterns reside in the domain of modules and interconnections. At a higher level there are Architectural patterns that are larger in scope, usually describing an overall pattern followed by an entire system.
Not all software patterns are design patterns. For instance, algorithms solve computational problems rather than software 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 it also improves code readability for coders and architects who are familiar with the patterns.
In order to achieve flexibility, design patterns usually introduce additional levels of indirection, which in some cases may complicate the resulting designs and hurt application performance.
By definition, a pattern must be programmed anew into each application that uses it. Since some authors see this as a step backward from software reuse as provided by components, researchers have worked to turn patterns into components. Meyer and Arnout claim a two-thirds success rate in componentizing the best-known 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.
We have Creational Patterns, Structural Patterns, Behavioral Patterns, Concurrency Patterns
Defining Design Patterns
We all talk about the way we do things in our everyday work, hobbies and home life and recognize repeating patterns all the time.
· Sticky buns are like dinner rolls, but I add brown sugar and nut filling to them.
· Her front garden is like mine, but, in mine I use astilbe.
· This end table is constructed like that one, but in this one, the doors replace drawers.
We see the same thing in programming, when we tell a colleague how we accomplished a tricky bit of programming so he doesn’t have to recreate it from scratch. We simply recognize effective ways for objects to communicate while maintaining their own separate existences.
Some useful definitions of design patterns have emerged as the literature in his field has expanded:
· “Design patterns are recurring solutions to design problems you see over et. al., 1998).
· “Design patterns constitute a set of rules describing how to accomplish certain tasks in the realm of software development.” (Pree, 1994)
· “Design patterns focus more on reuse of recurring architectural design themes, while frameworks focus on detailed design… and implementation.” (Coplien & Schmidt, 1995).
· “A pattern addresses a recurring design problem that arises in specific design situations and presents a solution to it” (Buschmann, et. al. 1996)
· “Patterns identify and specify abstractions that are above the level of single classes and instances, or of components.” (Gamma, et al., 1993)
But while it is helpful to draw analogies to architecture, cabinet making and logic, design patterns are not just about the design of objects, but about the communication between objects. In fact, we sometimes think of them as communication patterns. It is the design of simple, but elegant, methods of communication that makes many design patterns so important.
Design patterns can exist at many levels from very low level specific solutions to broadly generalized system issues. There are now in fact hundreds of patterns in the literature. They have been discussed in articles and at conferences of all levels of granularity. Some are examples which have wide applicability and a few (Kurata, 1998) solve but a single problem. It has become apparent that you don’t just write a design pattern off the top of your head. In fact, most such patterns are discovered rather than written. The process of looking for these patterns is called “pattern mining,” and is worthy of a book of its own.
The 23 design patterns selected for inclusion in the original Design Patterns book were ones which had several known applications and which were on a middle level of generality, where they could easily cross application areas and encompass several objects.
The authors divided these patterns into three types creational, structural and behavioral.
· Creational patterns are ones that create objects for you, rather than having you instantiate objects directly. This gives your program more flexibility in deciding which objects need to be created for a given case.
· Structural patterns help you compose groups of objects into larger structures, such as complex user interfaces or accounting data.
· Behavioral patterns help you define the communication between objects in your system and how the flow is controlled in a complex program.