Paradigm vs Pattern
I often hear the words “paradigm” and “pattern” used to describe sophisticated ways of solving problems that engineers encounter. However, these terms are frequently used interchangeably, as if they mean the same thing. In practice, both usage often seem to boil down to an oversimplified idea: an approach.
The situation becomes even trickier because both of these words are widely used across various scientific disciplines — such as philosophy, physics, biology and etc. So, let’s take an academic look at the actual meanings of these terms.
The word paradigm comes from greek and consists of 2 parts:
- παρά (para) - near, alongside
- δειγμα (deigma) - exemplar, pattern
Altogether, near-exemplar, alongside-pattern.
You see? It’s not getting easier. At its core, paradigm even seems to reference the idea of a pattern.
So, to “refactor” this ̶ ̶s̶p̶a̶g̶h̶e̶t̶t̶i̶ ̶c̶o̶d̶e̶ mess, let’s start with the word paradigm.
Paradigm represents dominant theories, concepts and research methods that are acceptable within a specific community.
A paradigm is what the members of a scientific community share, and, conversely, a scientific community consists of men who share a paradigm.
(T. Kuhn, The Structure of Scientific Revolutions)
We all know at least one such paradigm, it’s called Object-Oriented Programming (OOP). At its core, OOP is based on the idea that “everything is an object”. It comes with a set of principles for writing code: abstraction, encapsulation, polymorphism and inheritance. It also provides conventions for managing state and solid recommendation for writing maintainable code.
There is a broad community of OOP developers and theorists like the well-known “Uncle Bob”. The OOP paradigm also supports a wide range of research methodologies for addressing many problem domains.
Of course, OOP isn’t the only paradigm in software engineering. Another interesting one is the functional programming paradigm with its own blackjack and concepts.
Pattern refers to something shaped or designed to serve as a model for making something else. This concept is common in needlework, various forms of art and other crafts.
Let’s return to our engineering work. There are a variety of patterns that many engineers are familiar with, such as:
- design patterns
- deployment patterns
- analysis patterns
- {you_name_it} pattern
Design patterns are solutions to recurring problems; guidelines on how to tackle certain problems.
The above definition is well articulated, note that …recurring problems;
Factories, commands, strategies and other techniques are the building blocks of our codebases on a daily basis.
Let’s briefly explore some of the deployment patterns…
Another recurring problem: on every project engineers required to minimize downtime during deployments of new features. No problem, there’s a pattern for that -> blue-green deployment.
If we carefully analyze these patterns, we can notice two important nuances:
- each of them are used for very specific and narrow use-case
- it becomes obvious that we may not have a ready to use pattern if a problem we encounter is a new one
Consequently, I argue that a paradigm is a broader term, containing the dominant concepts and methods that together form a framework. This framework can be used to address a wide range of unique and complex problems but it is not a silver bullet.
While a pattern is a “smaller unit” that we often use to solve specific, recurring problems.
This distinction is important and should serve as our guide when exploring different kind of resource from books to one-page cheatsheets.
