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
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
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.
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.
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.
Christopher Alexander is the architect who first studied patterns in buildings and communities and developed a "pattern language" for generating them.
So the terms are not interchangeable, because they refer to different levels of design.
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.
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".