5

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/the 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?

Improve this question
3
  • 2
    Design pattern to algorithm is kinda like an abstract class to instance.
    – SF.
    Jul 12, 2011 at 12:08
  • 1
    @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, 2011 at 14:22
  • Calling a taxi is a general reusable solution to the commonly occurring problem of wanting to get from A to B.
    – gnasher729
    Apr 8, 2020 at 18:30

11 Answers 11

Reset to default
0

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).

Improve this answer
4
  • 3
    I don't think many people would think that "binary search" the common understanding of "design pattern". It's an algorithm. Its implementation might involve the various objects, methods, etc. The implementation might have various patterns that reoccur in other solutions. Those are design patterns. "Just like you shouldn't tell a math guy that all math is just basic addition (even though it's true)." Uhhh, no? Counterexample: calculating an intersection of two sets isn't reducable to addition.
    – Alexander
    Apr 8, 2020 at 16:31
  • Absolute nonsense.
    – gnasher729
    Apr 8, 2020 at 18:30
  • What!?I am a mech engineer trying to learn coding and even I know this answer is completely wrong.
    – GRANZER
    Jan 13, 2021 at 8:05
  • How can this be the accepted answer? It's just misleading.
    – Jason210
    Nov 1, 2021 at 9:20
15

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).

Improve this answer
4
  • 2
    +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, 2011 at 12:49
  • 1
    By that reasoning, e.g. "dynamic programming" is a design pattern, yet it's usually found in algorithms books.
    – nikie
    Jul 12, 2011 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 - MSFT
    Jul 12, 2011 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, 2011 at 0:49
5

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

Expanded: more helpful may be "finding answers" to these questions(you should try to answer them on your own):

  • 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.

Improve this answer
2
  • +1 for all but the first sentence.
    – user8709
    Jul 17, 2011 at 8:09
  • Agree, if doesn't make sense, why to answer:)
    – Dehumanizer
    Jul 17, 2011 at 12:31
4

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

Improve this answer
3

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.

Improve this answer
6
  • 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 - MSFT
    Jul 12, 2011 at 12:02
  • 1
    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, 2011 at 12:06
  • 1
    @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, 2011 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.
    – user8709
    Jul 17, 2011 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, ...).
    – user8709
    Jul 17, 2011 at 8:19
2

A design pattern is a generic term, originated in the book A Pattern Language by professor and design theorist Christopher Alexander and it can be applied to any field of human activity where patterns of problem solutions are well known. In the context of software development, this term immediately evokes the image of the famous book Design Patterns: Elements of Reusable Object-Oriented Software and 23 'classic' patterns so thoroughly explained in it. Some architects and authors refer to such design patterns (and there are hundreds of them) as Software Engineering Design Patterns (example, Strategy), to distinguish them from the Algorithmic Design Patterns also known as Algorithmic Paradigms (example, Divide and Conquer).

The Algorithm is also a generic term and all kinds of algorithms have existed since antiquity. In software context, this term refers to any set of computer instructions that can be executed within a finite amount of space and time. See Algorithm and Analysis of algorithms for more information.

Let me try to put all these terms in a single paragraph to clarify their differences: Usually students and computer scientists (or programmers) study existing algorithms or invent a new one (very rare though) in context of either a domain (for example, to solve a computation problem at hand) or a algorithm paradigm (for example, to improvise a specific technique of divide and conquer). Since an algorithm can be implemented in any language, the actual design and implementation in a particular language may benefit from Software engineering design patterns. Note that a newbie programmer might solve a domain problem without knowing any algorithm, algorithm paradigm or software engineering design pattern (the solution could be inefficient or hard to explain to others but that's a different concern).

One area of software development where I find their knowledge most useful is the communication within the team that is working on a problem. Well known algorithms, algorithm design patterns and software engineering design patterns almost always remove the architecture/design ambiguities (thus saving time and money) and allow team members to focus on design, development and testing and other important things.

Improve this answer
1

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.

Improve this answer
5
  • 1
    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, 2011 at 12:22
  • 1
    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, 2011 at 12:26
  • 1
    @Falcon: Detailed blueprints are the instructions for constructing a house.
    – Gilbert Le Blanc
    Jul 12, 2011 at 12:32
  • 1
    @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, 2011 at 13:11
  • 1
    @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, 2011 at 13:23
1

...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.

Improve this answer
1

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.

Improve this answer
1

Design patterns are about design in the large, ignoring many of the smaller details.

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.

Improve this answer
1

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)

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.