Although almost everyone believes that an algorithm solves a specific problem, a design pattern also solves a specific problem (e.g. notifying observers).
Lexically an algorithm is:
A process or set of rules to be followed in calculations or other
problem-solving operations, especially by a computer.
And the pattern is:
Pattern in architecture is the idea of capturing architectural design
ideas as archetypal and reusable descriptions. The term pattern in
this context is usually attributed to Christopher Alexander, an
Austrian born American architect. The patterns serve as an aid to
design cities and buildings.
In 1987, Kent Beck and Ward Cunningham
began experimenting with the idea of applying patterns to programming
– specifically pattern languages – and presented their results at the
OOPSLA conference that year. In the following years, Beck, Cunningham,
and others followed up on this work.(source:
Wikipedia)
And here is we can see the algorithm of documenting a design pattern. (Pattern Name and Classification, intent, structure, ...). This algorithm's output is a design pattern documentation.
The algorithm is basically a set of rules. And a design pattern is a well-tested set of steps (rules) to achieve a specific goal.
You cannot liken all algorithms to only a small piece that does only one thing in a machine.
In fact, an algorithm might consist of a whole machine as well. On the other hand, an algorithm can contain other algorithms.
We always think of algorithms as small pieces, because in real life everything can change, keeping algorithms small is more useful.
Let's assume people took their line numbers from a Qmatic (Queueing machine), and while everyone waiting for their turn, the break for lunch came and employees went out. Also, every customer went out as well.
If this scenario would be the same every single time, we would call all steps as an algorithm:
- After the break, every customer comes back.
- According to their line number they are ordered as small numbers first (First-In-First-Out method).
- A bank officer gets the EFT requirements one by one.
So, in this case, the queue is a data structure.
The people can be sorted using any sorting algorithm.
The officer's workflow can be called a design pattern, in certain conditions outputs will be certain things - like a group of math formulas. It never changes. If this workflow is the best way to give EFT order, it's useful to know these steps as an EFT ordering algorithm. Thus every bank can implement it.
However, in real life:
- Every customer is supposed to have come back, however, some of them give up because of their other plans, and some of them might be felt sick.
- Sorting algorithm (FIFO method) still works well!
- The bank officer has been taken to the hospital.
So, we can generate different best solutions for every possibility. Then we can version our algorithm like EFT ordering algorithm v1 - bank officer is sick, EFT ordering algorithm v2 - ... but it doesn't make sense.
Can we say a design pattern contains more than one algorithm? The answer is "yes, we can" and "no we can't". If we expect a result set like [1, 'phrase', , , { name: 'John Doe' }], well, probably our algorithm makes several different computational works.
And now, we knew that the only constant situation in the scenario above is the sorting algorithm. It's also compact and can be implemented in different industries.
Moreover, the current situation can be changed over time because of technological development or new governmental laws. Again, determining the steps above as an algorithm is unuseful.
In real life, this complicated situation is handled by bank companies. The bank that applies the most efficient workflow with customer satisfaction, became the first place in the banking industry. They try to improve their service using technology to make their customers happy and reduce costs.
This is why we can say design patterns are algorithms, and why we don't prefer to call design patterns as algorithms. Keep it small, simple...
