Lesson 4	What makes up a design pattern?
Objective	List the four key elements of a design pattern.

Design Pattern Components

Standard Names for Design Patterns

To some extent these names are not fixed.
For instance, the Abstract Factory pattern is also known as "Kit". Many other patterns have alternate names.
However, the names of the most common patterns are becoming de facto standards in the object-oriented community. Although names are to some extent arbitrary, nonetheless by agreeing on common names, programmers can communicate more easily and compactly. For example, if I need to explain the Java Cryptography API to a pattern-literate programmer, I simply say that

Cipher.getInstance()

is a Factory Method used to choose the right Template Method for the transformation. To explain the same thing to a non-pattern literate programmer would require me to spend several pages explaining the Factory and Template Method patterns.
This is similar in some respect to how a common set of data structures which all programmers are expected to know makes programs easier to explain, document, and understand. There is no need to constantly re-explain the same reusable material.

Motivation

Modularization is a challenge in today's programming and for this reason developers are trying to avoid the idea of adding code to existing classes in order to make them support the encapsulation of more general information. When using the Abstract Factory design pattern a framework is defined, which produces objects that follow a general pattern and at runtime this factory is paired with any concrete factory to produce objects that follow the pattern of a certain country. In other words, the Abstract Factory is a super-factory which creates other factories (Factory of factories).

Design patterns are a means to communicate, identify, and remember solutions to common problems. Each pattern names, explains, and evaluates a solution to a common problem. Each design pattern has four essential elements:

What are the Elements of a Design Pattern?

1) **Name:** The name of the pattern is one or two word description that pattern-literate programmers familiar with patterns can use to communicate with each other. Examples of names include 1) factory method 2) singleton 3) mediator 4) prototype. The name of the pattern should recall the problem it solves and the solution.

2) **Problem:** The problem the pattern solves includes a general intent and a more specific motivation or two. For instance, the intent of the singleton pattern is to prevent more than one instance of a class from being created. A motivating example might be to not allow more than one object to try to access a system's audio hardware at the same time by only allowing a single audio object.

The solution to the problem specifies the elements that make up the pattern such as the specific classes, methods, interfaces, data structures and algorithms. The solution, also includes the relationships, responsibilities and collaborators of the different elements. Indeed these interrelationships and structure are generally more important to the pattern than the individual pieces, which may change without significantly changing the pattern. — 3)**Solution:** The solution to the problem specifies the elements that make up the pattern such as the specific classes, methods, interfaces, data structures and algorithms. The solution, also includes the relationships, responsibilities and collaborators of the different elements. Indeed these inter-relationships and structure are generally more important to the pattern than the individual pieces, which may change without significantly changing the pattern.

4) **Ensemble Pattern:** Often more than one pattern can solve a problem. Thus the determining factor is often the consequences of the pattern. Some patterns take up more space and some take up more time. In addition, some patterns are more scalable than others.

Behavioral, Creational, Structural Types of Design Patterns

Name of the Pattern

The name of the pattern is a one or two word description that pattern-literate programmers familiar with patterns can use to communicate with each other. Examples of names include "factory method", "singleton", "mediator", "prototype". The name of the pattern should communicate to the programmer the problem it solves and the solution.

Big-O Notation

It is not possible to do a formal big-O analysis of different patterns as it is with algorithms, because patterns leave too much unspecified. However, it is possible to make general choices for what trade-offs do exist and which patterns are more suitable for which circumstances.

Four Elements of a Pattern

In general, a pattern has four essential elements:

The pattern name is a handle we can use to describe a design problem, its solutions, and consequences in a word or two. Naming a pattern immediately increases our design vocabulary and allows us to design at a higher level of abstraction. Having a vocabulary for patterns lets us talk about them with our colleagues, in our documentation, and even to ourselves. It makes it easier to think about designs and to communicate them and their trade-offs to others. Finding good names has been one of the hardest parts of developing our catalog.
The problem describes when to apply the pattern and explains the problem and its context. It might describe specific design problems such as how to represent algorithms as objects. In addition, it might describe class or object structures that are symptomatic of an inflexible design. Sometimes the problem will include a list of conditions that must be met before it makes sense to apply the pattern.
The solution describes the elements that make up the design, their relationships, responsibilities, and collaborations. The solution does not describe a particular concrete design or implementation, because a pattern is like a template that can be applied in many different situations. Instead, the pattern provides an abstract description of a design problem and how a general arrangement of elements (classes and objects in our case) solves it.
The consequences are the results and trade-offs of applying the pattern. Though consequences are often unvoiced when we describe design decisions, they are critical for evaluating design alternatives and for understanding the costs and benefits of applying the pattern. The consequences for software often concern space and time trade-offs and may address language and implementation issues as well. Since reuse is often a factor in object-oriented design, the consequences of a pattern include its impact on a system's flexibility, extensibility, or portability. Listing these consequences explicitly helps you understand and evaluate them.