Design Patterns

This post contains affiliate links, which means I may earn a commission if you make a qualifying purchase from them.

Last post, I talked about patterns for software development in general and that their worldwide adoption started with the publication of Design Patterns: Elements of Reusable Object-Oriented Software in 1994 (while I like owning a physical copy of this classic book, resources on patterns are also available for free on the internet).

Today’s topic is on design patterns. A pattern has the following anatomy:

• Name — identifies a unique pattern so that developers can easily refer to it and communicate the problem, the solution, and the consequences of using the pattern
• Problem — describes the recurring problem and the context in which the pattern can be applied
• Solution — describes the elements that compose the design, focusing on relationships, responsibilities, and collaborations
• Consequences — describes the results and trade-offs for using the pattern, allowing developers to evaluate it against other alternatives

The aforementioned book provides 23 design patterns for object-oriented programming classified by purpose and scope.

Purpose indicates the nature of problems that the pattern addresses. There are 4 kinds of purposes in programming, and the book covers 3 of them:

• Creational — creation of objects
• Structural — composition of classes and objects
• Behavioral — interaction and responsibility distribution between classes and objects
• Concurrency (not covered by the book) — multi-threading

Scope distinguishes if the pattern focuses more on classes or objects. Class-scope patterns address more static compile-time problems. Conversely, object-scope patterns concern with dynamic run-time issues.

Although design patterns were originally identified for object-oriented programming, many patterns apply to functional programming as well. The following notable patterns are commonly seen in functional programming: Strategy, Factory Method, Observer, Decorator, and Prototype.

I believe design patterns should be part of every developer’s arsenal of knowledge to help them with communicating and solving problems in a more standard fashion.

Originally published at https://sckpang.ca.