What's the difference between an Algorithm and a Design Pattern

Question

I was searching for "Undo/Redo algorithms" and found something marked as a duplicate, but the duplicate was a request for a "Undo Design Pattern". I'd really like an algorithm for this. I don't think I necessarily need a design pattern.

Is there a fundamental difference between "Design Pattern" and "Algorithm" or is it OK that someone uses the two interchangeably?

I'll hang up and take my answer off the air.

Ok, forgive me for thinking design patterns were just abstractions of algorithms. Here's a little table of my findings from the answers which were all very good.

   Design Pattern |    Algorithm
------------------|----------------
Abstract          | Concrete
Control Structure | Set of Actions    
Template          | Implementation
Flexible          | Deterministic
Blueprint         | Recipe

Answer 1

An algorithm is like a recipe: a step-by-step process for performing some activity.

A design pattern is like a blueprint: an structured collection of objects and associations and actions to accomplish some goal.

Answer 2

Yes, there is a difference.

An algorithm is a recipe for performing some task - an unambiguous finite set of instructions that achieves some goal by operating on an input and producing an output. Typically an algorithm is expressed in a language-agnostic pseudo-code, which can then be implemented in the language of your choice.

A design pattern is a way of structuring your code in order to elegantly express a relationship between functional components. You might use design patterns within the implementation of an algorithm. For example, you might use an algorithm for an in-order walk of a tree to ensure that you visit all the nodes of a tree data structure in a certain order. You might also implement a visitor design pattern to express how your implementation returns control to the calling context to indicate that a node has been visited. This is not part of the algorithm, but part of the software design, and how you structure the interfaces that each component of your software can use.

Algorithms and design patterns are orthogonal, although they may well both be used at the same time.

Answer 3

A design pattern is a relatively vague description of how to solve a problem at an architectural level, with emphasis on flexibility and maintainability. An algorithm is a precise description of how to compute something specific, with an emphasis on correctness and efficiency.

Answer 4

A design pattern can't be directly translated to code. It is a "strategy" that can be useful for the design of an application. The origin of the term is external to computer science. Read about Christopher Alexander to learn more.

An algorithm on the other side can be expressed in code. It is a sequence of operations that solve a specific problem for any input.

Answer 5

An algorithm is a set of steps/actions/commands/instructions that work in a specified order/manner across all circumstances or state changes. In the case of undo/redo, it would involve storing previous state at each juncture and then reproducing it (through whatever means the app has) on command. But since this definition is so fuzzy and each particular case is different, we like to create a more generalized design pattern into which a specific app's functionality can be plugged-in.

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. --SourceMaking

Christopher Alexander is the architect who first studied patterns in buildings and communities and developed a "pattern language" for generating them.

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. --Christopher Alexander

So the terms are not interchangeable, because they refer to different levels of design.

Answer 6

I would say that a design pattern defines structure, whereas an algorithm defines behaviour.

For example, you might use several different algorithms in conjunction with the Strategy design pattern.

Answer 7

An algorithm is a specific set of steps to perform a task. Decoding an audio or video file would use an algorithm.

A design pattern is more of a template for designing a system with certain characteristics.

Answer 8

they are different: http://en.wikipedia.org/wiki/Design_pattern_(computer_science) vs http://en.wikipedia.org/wiki/Algorithm

using the the command design pattern (http://en.wikipedia.org/wiki/Command_pattern), it is easy to implement undo/redo: http://www.cs.mcgill.ca/~hv/classes/CS400/01.hchen/doc/command/command.html

related question: Design Pattern for Undo Engine

Answer 9

When I studied design pattern concept for the first time, I was also surprised why design patterns were introduced in the presence of algorithm. As my knowledge has been increasing with design patterns, I am reaching at this point that algorithm is entirely different approach to solve the problems and design pattern is different.

Design pattern is basically a recurring solution of same problem for a software application in a particular context which is somehow not related with algo, because algorithm is the step by step instructions to solve the problem.

Answer 10

A design pattern would determine how you design an algorithm (or may have nothing to do with algorithms, but let's say we're dealing with one that does), whereas an algorithm will be a set of solid, repeatable, implementable, steps to doing something. So no, I wouldn't call them interchangable.

Answer 11

How to organize types of features rather than specific features might be key to separate 'design patterns' from 'algorithms'...

Design patterns describe generic solutions to common design problems. "Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice" (Christopher Alexander) In programming this is done by describing specific sets of relationships between software objects (standing in for conceptual or real world objects). Describing specific implementation should be avoided, because it makes the design pattern less generic.

An algorithm is a set of steps that define how a task is performed. The execution of each step in an algorithm does not require creative skills. Rather, it requires only the ability to follow directions. (warning: nondeterministic algorithms, do not conform to this restriction and are an important topic of research)

So, I think one description of the relationship might be to separate features from functions. However, the collection of features of an object will determine its function since each sub-feature has functions encapsulated in it. When you put together many small objects into one bigger object (e.g. instances of different classes into a program) some of them will work together to create new functions which they didn't have by themselves (the whole is greater than the sum of its parts). You can say that this is just a new algorithm, but it is also a new object. Features and functions are two sides of the same coin, so it is impossible to separate them completely. But how to organize types of features rather than specific features might be key to separate 'design patterns' from 'algorithms' since if design patterns are about organizing specific features, i.e. instances of specific classes, then the algorithm would already have been presented and the implementation would be exactly the same every time, i.e. it would not be generic and you can't "use this solution a million times over, without ever doing it the same way twice".

Answer 12

Design patterns:

• a solution to a common but generic problem.
• general solution to general problem.
• often have to be implemented each time it is used.

Algorithm:

• specific set of steps you can follow to answer particular problem.
• implemented directly to solve specific problem.

Answer 13

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:

1. After the break, every customer comes back.
2. According to their line number they are ordered as small numbers first (First-In-First-Out method).
3. 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:

1. 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.
2. Sorting algorithm (FIFO method) still works well!
3. 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...