Design Patterns vs. Algorithms

[Nathan Pruett]

I had not used nor heard of design patterns prior to the current project I am on. (I am just starting my 2nd year of job experience after college, so I'm at least 10 years behind the industry. That's what a CS degree will do for you...) One of the people developing the system began talking about using Adapter and Mediator patterns in the system being developed, I was curious and went off to look up info on design patterns online.
Anyway, after looking at some info on design patterns how are they any different than algorithms? (albeit at a higher level of system design.) Algorithms are basically described as "a set procedure to solve a certain problem, broken down into steps." Design patterns look like they do this also, just in a more OO way...
In fact, I remember from my Algorithms class that a computer scientist (I believe Robert Sedgewick) collected lots of algorithms, catagorized them, and somewhat standardized them. Kinda what's being done with design patterns now.
Basically, what I'm asking is this : Are design patterns just a new, cool, OO word for algorithms, or am I just oversimplyfying the idea?
-Nate

[Mirko Froehlich]

Nate,
No, design patterns are not just an OO version of algorithms. I like your comparison, and there might be a few similarities, but design patterns (as you point our yourself) are used on a much higher level of design. They will help you design an application, but they will not solve specific problems - for these, you will still need to develop or use existing algorithms.
-Mirko

Originally posted by Nathan Pruett:
I had not used nor heard of design patterns prior to the current project I am on. (I am just starting my 2nd year of job experience after college, so I'm at least 10 years behind the industry. That's what a CS degree will do for you...) One of the people developing the system began talking about using Adapter and Mediator patterns in the system being developed, I was curious and went off to look up info on design patterns online.
Anyway, after looking at some info on design patterns how are they any different than algorithms? (albeit at a higher level of system design.) Algorithms are basically described as "a set procedure to solve a certain problem, broken down into steps." Design patterns look like they do this also, just in a more OO way...
In fact, I remember from my Algorithms class that a computer scientist (I believe Robert Sedgewick) collected lots of algorithms, catagorized them, and somewhat standardized them. Kinda what's being done with design patterns now.
Basically, what I'm asking is this : Are design patterns just a new, cool, OO word for algorithms, or am I just oversimplyfying the idea?
-Nate

[shailesh sonavadekar]

You can say that Design Patterns are great boon to s/w professional. The thigs that were there in the minds of exp. professionals , was put it on the paper. Those things were known to people. But formal name was not there.
It is really commendable job done by Gang of Four to come out with atleat 23 patterns with thier epic book. You can say that it greatly facilitates communication between programmer & leader. For example , if project leader sees some recurring thing & idetifies the pattern , he / she will just tell the programmer , " use factory or use bridge or use composite ". With one word your entire design is over & speedy & efficient communication is achieved.

Thus , I feel Patterns are going to become lifeblood of s/w industry. They are more than algorithms.
I hope this can be useful.
Shailesh.

[Tony Chen]

This comparison might not be correct:
Old Programs = Data Structures + Algorithms
New Applications = Classes + Design Patterns

[Anand Dharia]

Nathan
here is a para from a book on Design Patterns By Bruce Eckel
hopr this will solve your query
-----------------------------------------------------------------
What is a pattern?
Initially, you can think of a pattern as an especially clever and insightful way of solving a particular class of problems. That is, it looks like a lot of people have worked out all the angles of a problem and have come up with the most general, flexible solution for it. The problem could be one you have seen and solved before, but your solution probably didn�t have the kind of completeness you�ll see embodied in a pattern.

Although they�re called �design patterns,� they really aren�t tied to the realm of design. A pattern seems to stand apart from the traditional way of thinking about analysis, design, and implementation. Instead, a pattern embodies a complete idea within a program, and thus it can sometimes appear at the analysis phase or high-level design phase. This is interesting because a pattern has a direct implementation in code and so you might not expect it to show up before low-level design or implementation (and in fact you might not realize that you need a particular pattern until you get to those phases).

The basic concept of a pattern can also be seen as the basic concept of program design: adding a layer of abstraction. Whenever you abstract something you�re isolating particular details, and one of the most compelling motivations behind this is to separate things that change from things that stay the same. Another way to put this is that once you find some part of your program that�s likely to change for one reason or another, you�ll want to keep those changes from propagating other changes throughout your code. Not only does this make the code much cheaper to maintain, but it also turns out that it is usually simpler to understand (which results in lowered costs).

Often, the most difficult part of developing an elegant and cheap-to-maintain design is in discovering what I call �the vector of change.� (Here, �vector� refers to the maximum gradient and not a container class.) This means finding the most important thing that changes in your system, or put another way, discovering where your greatest cost is. Once you discover the vector of change, you have the focal point around which to structure your design.

So the goal of design patterns is to isolate changes in your code. If you look at it this way, you�ve been seeing some design patterns already in this book. For example, inheritance can be thought of as a design pattern (albeit one implemented by the compiler). It allows you to express differences in behavior (that�s the thing that changes) in objects that all have the same interface (that�s what stays the same). Composition can also be considered a pattern, since it allows you to change�dynamically or statically�the objects that implement your class, and thus the way that class works.

You�ve also already seen another pattern that appears in Design Patterns: the iterator (Java 1.0 and 1.1 capriciously calls it the Enumeration; Java 2 containers use �iterator�). This hides the particular implementation of the container as you�re stepping through and selecting the elements one by one. The iterator allows you to write generic code that performs an operation on all of the elements in a sequence without regard to the way that sequence is built. Thus your generic code can be used with any container that can produce an iterator.
-----------------------------------------------------------------

[Rahul Mahindrakar]

Hi,
An algorithm is basically a solution at the coding level. One tries to find the best algorithm to get the work done fast. As Nathan says

Algorithms are basically described as "a set procedure to solve a certain problem, broken down into steps."

Design patterns are solutions to common problems encountered while providing a software solution. There is no such thing as getting things done fast in Design patterns. It is getting the work done so that the objects may be reused or changes can be made easily. There may be other objectives of a design pattern. But this cannot be quantified like the time taken in a particular algorithm. Thus Design patterns is an art.

To understand patterns let us look of what types they are
Creational Patterns : Looks at how objects can be created
Structural Patterns : Looks at how objects are brought together.
Behavioural Patterns : Looks at how objects communicate.
Patterns thus looks at the Object and Objects level. while an algorithm looks at how the Objects are coded.

[Linda Rising]

Originally posted by Nathan Pruett:

Basically, what I'm asking is this : Are design patterns just a new, cool, OO word for algorithms, or am I just oversimplyfying the idea?
-Nate

Hi,
The discussion in this thread is very good and I think your question has been answered -- is that true?
One thing that is similar in the algorithm/pattern issue is the name. If you say you are a CS grad or put forward some other set of credentials, your team would expect that they could say "Binary Search" and not have to explain it. You would not only know what it was but whether it was appropriate for the problem at hand. Now you may not remember how to implement it :-)! You might have to look it up -- but you would also know how to do that!
Ideally, pattern use should be the same. Your team would expect that if they say "Mediator" you would know what it was and whether it was appropriate. You might have to look up an example to help with the implementation but you could do that easily.
The names used in this way almost make a language that makes the entire design process flow faster and more efficiently.
To help your vocabulary :-)! get a copy of the Pattern Almanac or win one this week -- and enjoy!

Linda

------------------
Linda Rising
Author of The Pattern Almanac 2000

[Tony Chen]

Patterns and Software: Essential Concepts and Terminology by Brad Appleton
Patterns and Algorithms
The previous section about patterns versus rules also applies in large part to algorithms and their data structures. Certainly, algorithms and data structures may be employed in the implementation of one or more patterns, but algorithms and data structures generally solve more fine-grained computational problems like sorting and searching. Patterns are typically concerned with broader architectural issues that have larger-scale effects. The design patterns in [GoF] address people and development issues like maintainability, reusability, communicating commonality and encapsulation variation. These are issues that matter to the people who need to create and evolve/grow these software systems over time.
Algorithms and data structures are usually concerned almost exlusively with optimizing space or time or some other aspect of computational complexity and resource consumption. They are about finding the most compact and efficient means to perform some important computation or store and recall its results. Such algorithms and data structures are rarely concerned with compromises and tradeoffs regarding other concerns that other concerns that have little to do with things like performance or memory, and more to do with things like maintainability and adaptability and (re)usability of the architecture.
There are a great many books of algorithms and data-structures that provide source code and quantitative analysis for structures like AVL trees or splay-trees. But in many of these same textbooks there is little mention of how to implement these structures in ways that emphasize maintainability and adaptability and reuse; and when they do there is a whole new set of issues to worry about (like maintainability and reusability and encapsulation). Looking at the computational time and space aspects alone simply doesn't address the fuller set of forces that affect the architects and implementors as well as the users.
This is why algorithms and data structures tend to be more fine-grained than patterns: Because they mostly address issues of computational complexity, and not so much the underlying issues of the people who are both using and building the software. Patterns fundamentally address people issues (like maintainability) more so than simple hardware and software efficiency/memory issues.
Of course software developers need to be concerned both with finding appropriate architectures and with finding appropriate solutions to computational problems. So there will always be a need for patterns as well as for algorithms and data structures (and their use together).