A design pattern defines a way in which we can organize our solution to a given problem. It does not define algorithms that can be used to solve the problem, but rather provides an abstraction about how, for example, the code should be organized, what classes need to be defined, what their granularity will be, and how the different objects will be created.

The design patterns have gained a lot of traction, and the book Design Patterns: Elements of Reusable Object-Oriented Software, though published in 1994, still serves as a de facto reference when trying to understand design patterns.

A design pattern will usually consist of the following elements:

• A problem statement: A problem statement describes what we want to solve and hence also defines the design patterns we can use. The problem statement will tell us about the scope of the design that we are planning to pursue, the constraints that we may need to take care of, and at times how the different components will communicate with each other in the application.
• The solution: A solution describes the design that makes up for the problem. It goes into detail about how the class hierarchies should be formed, how the objects will be formed, the relationship between the objects, and how the communication will take place between the different components. The solution will be an abstract design, not specifying the details of the implementation. This makes the solution generic, to be applied to a class of problems, without caring about what algorithms should be used to solve a particular problem.
• The consequences: In the world of software development, nothing comes for free. Everything has a cost, and we trade off one thing for another. What matters is whether the trade-off is justifiable or not. The same applies to the choice of design patterns, which come with consequences of their own. Most of the time, these consequences are in the terms of space and time trade-offs, and form an important part of evaluating alternative options if a particular design choice is not justifying the cost of trade-offs. Sometimes, the consequences may also define the implementation barriers of a language, and can often impact the reusability and flexibility of an application.

The choice of a design pattern is not something that is common for every set of problems. What pattern will be used to solve the problem will be based upon several factors, such as the interpretation of the problem by the developers, any restraints on the programming language that need to be used, the deadlines associated with the project, and so on.