Behavioral patterns are concerned with the flow of control through a system. Some ways of organizing control within a system can yield great benefits in both efficiency and maintainability of that system. Behavioral patterns distill the essence of proven practices into readily understood, well known, and easy-to-apply heuristics.
Following is the list of all Behavioral patterns:
Structural patterns describe effective ways both to partition and to combine the elements of an application. The ways structural patterns affect applications varies widely: for instance, the Adapter pattern can let two incompatible systems communicate, while Facade lets you present a simplified interface to a user without removing all the options available in the system.
Following is the list of structural patterns :
Here is a demo to use jQuery for left hand side menu.
These patterns support one of the most common tasks in object-oriented programming—the creation of objects in a system. Most OO systems of any complexity require many objects to be instantiated over time, and these patterns support the creation process by helping to provide the following capabilities:
Generic instantiation – This allows objects to be created in a system without having to identify a specific class type in code.
Simplicity – Some of the patterns make object creation easier, so callers will not have to write large, complex code to instantiate an object.
Creation constraints – Some patterns enforce constraints on the type or number of objects that can be created within a system.
The following is the list of creational design patterns:
The 23 design patterns covered in the original Design Patterns book had several known applications and 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 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.
We have found that, regardless of the language, learning design patterns is a three-step process.
Acceptance
Recognition
Internalization
First, you accept the premise that design patterns are important in your work. Then, you recognize that you need to read about design patterns so you will know when you need them. Finally, you internalize the patterns in sufficient detail that you know which ones might help you solve a given design problem.
For some lucky people, design patterns are obvious tools, and these people can grasp their essential utility just by reading summaries of the patterns. For many of the rest of us, there is a slow induction period after we've read about a pattern followed by the proverbial "Aha!" when we see how we can apply them in our work. This book takes you to that final stage of internalization by providing complete, working programs that you can try out yourself.
The examples in Design Patterns are brief and are in C++ or, in some cases, Smalltalk. If you are working in another language, it is helpful to have the pattern examples in your language of choice. This book attempts to fill that need for C# programmers.
We all talk about the way we do things in our jobs, hobbies, and home life, and we 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 I grow as till be in my garden.
This end table is constructed like that one, but in this one, there are doors instead of 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 this field has expanded.
Design patterns are recurring solutions to design problems you see over and over. (The Smalltalk Companion)
Design patterns constitute a set of rules describing how to accomplish certain tasks in the realm of software development. (Pree 1995)
Design patterns focus more on reuse of recurring architectural design themes, while frameworks focus on detailed design and implementation. (Coplien and 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, Johnson, and Vlissides, 1993)
But while it is helpful to draw analogies to architecture, cabinetmaking, and logic, design patterns are not just about the design of objects but about the interaction between objects. One possible view of some of these patterns is to consider them as communication patterns.
Some other patterns deal not just with object communication but with strategies for object inheritance and containment. It is the design of simple, but elegant, methods of interaction 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 hundreds of patterns in the literature. They have been discussed in articles and at conferences of all levels of granularity. Some are examples that apply widely, and a few writers have ascribed pattern behavior to class groupings that apply to just a single problem (Kurata 1998).
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 it is worthy of a book of its own.
It Came From Outer Space... via U.C. Berkeley
The inspiration for design patterns in software development is usually attributed to Christopher Alexander, a professor of architecture at U.C. Berkeley. In the late ‘70s, he published several books that introduced the concept of patterns and provided a catalog of patterns for architectural design.
Alexander's work sparked interest in the object-oriented (OO) community, and within the next decade, a number of pioneers had developed patterns for software design. Kent Beck and Ward Cunningham were among the first, discussing a set of Smalltalk design patterns in a presentation at the 1987 OOPSLA conference. James Coplien was another who actively promoted the tenets of patterns, writing a book about C++ idioms, or patterns for C++ development, in the early ’90s.
OOPSLA was an excellent venue for the growing patterns community, since it offered an environment for them to share their ideas. Another important forum for the evolution of the patterns movement was the Hillside Group, established by Kent Beck and Grady Booch.
Probably the best-known contribution to the popularity of design patterns was the 1995 book Design Patterns: Elements of Reusable Object-Oriented Software. The authors—Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides—are also commonly known as the “Gang of Four” or GoF. The book introduced a comprehensive pattern language, and gave C++ examples for the patterns discussed. Another important work that gave momentum to patterns was the book Pattern-Oriented Software Architecture, A System of Patterns, by Buschmann, Meunier, Rohnert, Sommerlad and Stal.
Sitting at your desk in front of your workstation, you stare into space, trying to figure out how to write a new program feature. You know intuitively what must be done, what data and what objects come into play, but you have this underlying feeling that there is a more elegant and general way to write this program.
In fact, you probably don't write any code until you can build a picture in your mind of what the code does and how the pieces of the code interact. The more that you can picture this "organic whole," or gestalt, the more likely you are to feel comfortable that you have developed the best solution to the problem. If you don't grasp this whole right away, you may keep staring out the window for a time, even though the basic solution to the problem is quite obvious.
In one sense you feel that the more elegant solution will be more reusable and more maintainable, but even if you are the sole likely programmer, you feel reassured once you have designed a solution that is relatively elegant and that doesn't expose too much internal inelegancy.
One of the main reasons that computer science researchers began to recognize design patterns is to satisfy this need for elegant, but simple, reusable solutions. The term design patterns sound a bit formal to the uninitiated and can be somewhat off putting when you first encounter it. But, in fact, design patterns are just convenient ways of reusing object-oriented code between projects and between programmers. The idea behind design patterns is simple: write down and catalog common interactions between objects that programmers have frequently found useful.
One of the frequently cited patterns from early literature on programming frameworks is the Model-View-Controller framework for Smalltalk (Krasner and Pope 1988), which divided the user interface problem into three parts, as shown in Figure 1-1. The parts were referred to as a data model, which contains the computational parts of the program; the view, which presented the user interface; and the controller, which interacted between the user and the view.
Figure 1-1 The Model-View-Controller framework
Each of these aspects of the problem is a separate object, and each has its own rules for managing its data. Communication among the user, the GUI, and the data should be carefully controlled, and this separation of functions accomplished that very nicely. Three objects talking to each other using this restrained set of connections is an example of a powerful design pattern.
In other words, design patterns describe how objects communicate without become entangled in each other's data models and methods. Keeping this separation has always been an objective of good OO programming, and if you have been trying to keep objects minding their own business, you are probably using some of the common design patterns already.