# Does it make sense to ask, “What is the difference between Design Pattern and Algorithm?”

From Wikipedia:

In mathematics and computer science, an algorithm is an effective method expressed as a finite list of well-defined instructions for calculating a function.

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.

By description(assuming they are correct on Wikipedia), it appears that Algorithm and Design Pattern are somewhat similar/same. They both achieve the task of solving a problem and both are certainly reusable if properly implemented.

Does it make any sense to compare them to evaluate differences between them?

-
Design pattern to algorithm is kinda like an abstract class to instance. – SF. Jul 12 '11 at 12:08
@SF - I would probably argue that design patterns are to algorithms like data structures are to functions, or OOP is to functional programming. – Austin Hyde Jul 12 '11 at 14:22

A binary search is a design pattern. It's a problem that pops up all the time and the same pattern (binary search) solves it.

There is no difference between design patterns and algorithms from a mathematical level. Now if your talking to another human you should probably not say this because they are not capable of reducing ideas to their base components. Just like you shouldn't tell a math guy that all math is just basic addition (even though it's true).

-

You are missing the critical distinction. One is a 'design' and the other is a 'solution'.

The design pattern is used to design your classes, methods relative to each other. Think of it as a diagram.

The algorithm is used to solve a problem in a list of steps.

Try to search for the factory design pattern and the divide and conquer algorithm. Look at the differences between the two and you will see they are completely separate things.

-
So that means, Design Patterns would only include the Signature for a function, but no implementation, which is a solution provided by the necessary Algorithm? – Shamim Hafiz Jul 12 '11 at 12:02
Yes, you could look at it like that. Try to search for the factory design pattern and the divide and conquer algorithm. Look at the differences between the two and you will see they are completely seperate things. Maybe think of a design pattern as a diagram and an algorithm as a list of steps. – Ross Jul 12 '11 at 12:06
@Ross I like your last sentence, but I would modify it to say a design pattern is structure and an algorithm is a list of steps. – jimreed Jul 12 '11 at 12:31
A design pattern is a boilerplate solution to a design problem. Just because "design" is appropriate, doesn't mean "solution" isn't. OTOH, algorithms are rarely complete solutions for any real-world problem. They are even designs - have you never heard the term "algorithm design". I'm not sure it's possible to boil this down to a single sentence, though, without either losing the point or using imperfect-choice words. After all, using the perfect terms, "One is a 'design pattern', the other is an 'algorithm'." - not helpful. – Steve314 Jul 17 '11 at 8:16
BTW - there's no such thing as "the divide and conquer algorithm" - you're referring to an "algorithm paradigm", which is sort-of a design pattern for algorithms (fill in the divide step here, the combine step here, ...). – Steve314 Jul 17 '11 at 8:19

Using a construction analogy, the algorithm is the detailed architectural blueprints for a house, while design patterns are the wall, door, and window components that go into the detailed architectural blueprints.

-
I would've upvoted the answer, but I do not concur with the algorithm being the architectural blueprints. More like: The architecture is composed of patterns, like doors and windows. The algorithm is the way the door opens. Algorithms are more behaviour-like and less structural. – Falcon Jul 12 '11 at 12:22
I disagree. Not specific doors and walls. More like concepts that make up the blueprint: circular corridor vs tree corridor layout, spiral staircase around the stair well vs multiple narrow staircases, sloped roof vs flat roof. They decide upon people's traffic patterns, convenient rooms layouts and layout conforming to regulations, not specific size and material of specific doors. – SF. Jul 12 '11 at 12:26
@Falcon: Detailed blueprints are the instructions for constructing a house. – Gilbert Le Blanc Jul 12 '11 at 12:32
@Gilbert: You're analogy doesn't fit the question so well imho. I know what you mean and I totally understand your point. You see the process of building a house, where you use patterns for components which you are putting together. But the analogy shouldn't be about the process of building a house, but, really OOP-Like, about the house's structure and its behaviour. And then the algorithm isn't the architectural blueprints (and never was) as it already exists. It's very much like you see it from a code generators point of view. – Falcon Jul 12 '11 at 13:11
@Falcon: Perhaps you're correct. Referring to your first comment, your door opening algorithm is a class method. One part of an overall algorithm for constructing the whole house. But yes, the door opening method is also an algorithm. – Gilbert Le Blanc Jul 12 '11 at 13:23

A design pattern is a general guideline for how to go about writing and organizing a piece of code.

An algorithm is a specific set of steps that can be used to solve a problem.

Said a different way, a design pattern is about how you do something without much concern of what the actual goal is. Whereas, an algorithm is about exactly what you are trying to do, but may or may not, include information about what the actual implementation should be (in the code).

-
+1: Algorithm is "Finite, Definite and Effective". Design pattern is "Solution to a problem in a context with consequences." I don't see any confusion between the terms. – S.Lott Jul 12 '11 at 12:49
By that reasoning, e.g. "dynamic programming" is a design pattern, yet it's usually found in algorithms books. – nikie Jul 12 '11 at 13:19
@nikie: That means, if Dynamic Programming is a Design Pattern, then LCS and Matrix-Chain-Multiplication are Algorithms, implementing that Design pattern, right? – Shamim Hafiz Jul 12 '11 at 17:45
By that reasoning you cannot say Dynamic Programming is a design pattern. Dynamic Programming is not a design pattern. It's a generalized algorithm. It describes a way to save calculations so that you do not need to recalculate. This is different from any other design pattern; say a wrapper pattern which is where you wrap a class to adapt it to another interface. completely different. – Ross Jul 13 '11 at 0:49

It makes as much sense as asking about the difference between a car and a driveshaft.

-

...problem: print out a multiplication table, for all numbers 1-10.

Algorithm:

loop 1-10 over first control variable. For each iteration loop 1-10 over the second control variable. For each of these iterations, in order, print out product of the two variables.

Now, using design patterns. In particular,

Design pattern - Double-nested loop:

loop given range over first control variable. For each iteration loop given second range over second control variable. For each of these iterations perform specific operation on control variables.

Now rewriting the algorithm using design patterns:

Algorithm:

Apply double-nested loop in ranges 1-10, 1-10, printing out products of control variables.

-

An algorithm is a mathematical solution to a problem. It describes the mathematical steps required to get from your problem dataset to your solution. Think of it like a proof.

Many mathematical proofs follow similar themes. Proof by induction, proof by composition, reductio ad absurdum, etc. These can be likened to design patterns. These proof patterns aren't enough to prove a concept by themselves, but they provide a good plan of attack for solving your problem, and similarly a design pattern can provide a good plan of attack for developing a working algorithm.

-

Algorithms are about design in the small - often within a single function. Data structures aren't much bigger, generally needing a few algorithms to implement them, but not needing a design pattern.

The building blocks that are glued together by a design pattern are objects, and their methods usually implement algorithms and data structures. Always really, but that includes a lot of algorithms that we wouldn't normally call algorithms.

-

Quick answer - no, it doesn't make sense.

• describe/implement a design pattern, which sorts an array of integers (just for instance);
• which design pattern solves the graph shortest path problem?
• describe an algorithm, which implements a separation of data (the model) used in application from its presentation to user.
• ...

P. S. If the answer seems too dummy, feel free to comment it.

-
+1 for all but the first sentence. – Steve314 Jul 17 '11 at 8:09
Agree, if doesn't make sense, why to answer:) – Dehumanizer Jul 17 '11 at 12:31

An algorithm is a code construct that performs some job. A design pattern is a coding concept or rule that is a recognized "best practice" to follow in cases where it applies, while building algorithms. Each one may be the basis of the other.

Let's make an analogy to actual architecture. Architects can design houses of virtually limitless shapes and sizes. They can incorporate aesthetic or structural ideas from just about anywhere. However, there are some rules and "best practices" that architects should follow with regard to the structure of their designs. Doors should usually be at least 7 feet in height and at least 30" wide. This allows people to actually go through them. The stove and fridge should probably be in the same room as the oven, and there shouldn't be carpet in that room, which we call the "kitchen". Some patterns are optional; an architect can design a large "open concept" incorporating sub-spaces designed for various uses, or the architect can separate all of these spaces with walls. "Open concept" is the pattern; it doesn't have to be followed, as there are other patterns that will accomplish the same goal of providing various spaces, and won't collapse the house or burn it down.

More specifically, there are "patterns" of structural design that the actual carpenters should follow. Floor joists should be 12 inches apart, and should have cross-bracing every four feet. Floors in areas that will likely have a lot of water contact should have a waterproof underlayment beneath a water-tolerant surface material. Tile laid on a wood floor should have a form backing to minimize flex which causes cracking. Walls should have studs every 16 inches. Walls running perpendicular to the ceiling joists are "load-bearing" and should have double top plates. Windows should be framed with a header between two "king" studs, with additional "jack" studs inside the king studs supporting the header from underneath. It is certainly possible to frame a window within a wall without following these rules, but these rules create a more solid window frame that won't bow or sink into the wall over time under the weight of all the materials the wall is holding up. They are the "best practice", and in the real world are required by law to be followed in the interests of structural safety. These are rules you simply have to follow at a fine-grained level to build a solid house. Others are optional, or "either-or": you "may" drill through the studs of a wall to fish electrical wire, or you "may" instead run the wire up through and then across the top plate of the wall. There are recommendations, and things that are easier to do in one case versus another, but either is fine to do if you want to. There are also "minimum" guidelines: you "may" use either 12g or 14g electrical wire for a 120V 15A circuit in your home. However, 230V, or 20A+, must be 12g. You could, if you had it, use 10g for any of this, but that might be considered over-engineering.

So, in our analogy, the framing "design pattern" is the best practice for creating a window "algorithm" which allows people to see to the other side of the larger "wall" algorithm which has similar patterns for its construction, and supports a piece of the "house" program, and also divides it into "room" subfeatures which follow their own design patterns, and have "floor" algorithms which are designed for specific desirable characteristics.

Programming is very similar in several respects; there are certain rules that good developers follow to create robust code that can be easily maintained (DRY, SOLID, YAGNI), which lead to known "best practices" for following those rules (Strategy, Factory, Adapter). Then there are other rules that create performant algorithms that come HIGHLY recommended, but aren't required IF certain conditions are met (this SelectionSort will only ever see lists of 10 items, so even in the worst case it will meet performance expectations). And finally, there are optional or "either-or" cases where multiple patterns will follow all the rules, and it's up to you which is easier (Strategy or Template Method for this ETL algorithm? Depends on how much is common, and programmer preference)

-