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
Control Structure |Set of Actions
OOP |Structured / OO Programming
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
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.
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.
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.
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.
A design pattern is a more abstract concept that exists within object-oriented programming as a result of objects' encapsulation of their inner values and workings and polymorphism allowing for potentially different behaviors from the "same" function calls. All this makes it possible to build control structure into the objects' interaction rather than into an algorithmic structure like a conditional or a loop, and can be much simpler since you don't need to know an object's details to make it work - you only need to know that the object works. In the case of undo/redo, there could be objects for remembering state, for reproducing state, and for managing control. They would communicate with each other by calling methods/functions, which would each handle their own part of the functionality.
The terms are not interchangeable because they refer to different levels of design, and DP's in particular are only a part of object-oriented programming.
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 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.
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
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.
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.
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".
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.