Design patterns are solutions to common software development problems, and aim to facilitate the development of a software project. A solution must have proven effectiveness and be highly reusable (can be applied to different design problems in different circumstances) to become a design pattern.

A pattern describes a problem that happens over and over again in our environment, and then explains the core of the solution to that particular problem. Since it is just a scheme of the solution, the application of this pattern is not literal: it requires adaptation. You could use the same pattern a thousand times, and never repeat the way you applied it.

Software design patterns aim to:

  • Provide reusable elements in the design of software projects
  • Avoid spending time in the search of a solution to well-known and previously solved problems
  • Standardize the process of designing software applications
  • Facilitate the learning process of new generations of software developers and designers

Software design patterns are not used for:

  • Imposing some alternatives against others: there are plenty of design patterns out there, and the software engineer must compare all of them and choose the one that best suits the needs of the project, if any at all.
  • Erase the creativity inherent to software design: these patterns are a just a guide to an easier design process, a set of advices to follow. Developers can choose to either follow these rules or adapt them to better fit requirements.

These patterns are only recommended in case we’re facing a similar problem that the pattern addresses, having always in mind that it could just not be applied to our particular case. Abusing or forcing the use of design patterns can be a mistake.

In brief, a pattern is a common structure that similar applications have. This happens in all levels of life. For example, in our ordinary life we apply the pattern “greeting – introduction– message – farewell” in many different occasions. If you don’t think patterns are useful, then try to use the scheme “farewell – message – introduction – greeting” and see what happens.

The most widespread catalogue of design patterns can be found in the book Design Patterns: Elements of Reusable Object-Oriented Software, from Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides (1995, Addison-Wesley), AKA GOF (Gang-Of-Four). According to this book, design patterns can be categorized regarding the purpose they have been defined for:

  • Creational patterns: solve instance creation problems. They help in encapsulating and abstracting these creations.
  • Structural patterns: solve class and object composition problems.
  • Behavioral patterns: solve problems about interaction and responsibilities among classes and objects.

Software design patterns are usually easy to understand. What might get you more headaches might be using them. They really help and make software development less problematic, so it is very important to get to know some of them. I’ll mention some of them in the next few posts.

Further reading

Related posts:

  1. Software design patterns (II): creational patterns
  2. Software design patterns (III): structural patterns
  3. Software design patterns (IV): behavioral patterns
  4. Improving software quality: automatic testing