I've been reading various programming styles like XP (writing the test first), and came across a Java book that just has design patterns, what seems to be like pseudocodes.
What are these design patterns used for ? what does design apttern in the context of programming refer to and what are it's applications ? Is it like blue prints for building a domain specific application ?
You've got it right when you call design patterns "blue prints".
They are a "standard" way of solving problems that you can adapt to your circumstances. A complete description of the pattern should include the edge/corner cases making it more straightforward for you to code your solution.
You still have to ensure that you are choosing the correct pattern that will solve your problem and also know when and where it applies and, perhaps more importantly, where it doesn't apply.
It's not a "silver bullet" that will write your code for you.
Test-driven development, which you used as your example, isn't really a "design pattern".
Design patterns are ways of structuring your program to solve common, but abstract problems. A classic example is the Factory pattern. When you want to encapsulate (i.e., prevent the caller from messing with) aspects of object creation, you use a Factory to handle the process of making a new object.
You might want to run a Google search for the "Gang of Four", who wrote the textbook on design patterns (found here).
Design patterns are ways to describe solutions to common problems. They are not a specific piece of code and can often be implemented in different ways.
If you look at engineering for example, a design pattern could be "a wheel". There may be a lot of different kinds of wheels but there's a general idea of a "wheel" that stays the same.
In software development there are similar ideas that "just work" for a common problem and if you tell another developer that you used a "factory" for example, he roughly knows what you mean, just as an engineer roughly knows what you'd mean by "wheel".
So, design patterns are a way to clarify communication between developers and serve as reusable ideas. They are a bit like libraries for more abstract programming solutions that are mostly independent of the actual language that you use.
Yes, but on a smaller level, they're not blueprints for an entire application, but for problems you typically encounter while you build an application.
For example, when you want to create instances of different objects depending on a string. You might try a long series of ifs, later notice that's inefficient attempt to do it through your language's reflection capabilities, then notice that's inflexible and come up with an associative list that maps strings different functions creating instances of different classes.
This final solution works great and is pretty elegant, so you'll use similar techniques when you encounter similar problems in the future without trying all the dead-ends first. Congratulations, you just invented a design pattern.
In 1994, the "Gang of Four" (Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides) had the idea to collect these kinds of recurring patterns and publish them in a book they called "Design Patterns".
The advantage of knowing those patterns are, of course, that you can put a name to the techniques you use (making it easier to discuss class design with other people on a higher level) and that other programmers aware of design patterns will name their constructs similarly (so you'll recognize them in their code).
A Design Pattern is a general reusable solution to a commonly occuring design problem. Actually, we can generalize that: A Pattern is a general reusable solution to a commonly occuring problem. There are not only Design Patterns, there are also Coding Patterns (although we don't call them that, we call them Idioms), Architecture Patterns, User Experience Patterns, Process Patterns etc.
However, there is a small problem with that definition: in programming, we call a general reusable solution to commonly occuring problem a Program. So, in other words, if you have a recurring problem, you write a program, and only if you can't write a program, then you need a Pattern.
So, an alternative definition would be: A Pattern is a Program that you cannot write because your Programming Language is too weak to express it.
So, in general, you should try to use a better Programming Language before you try a Pattern. However, Programming Language Design is all about trade-offs: it's simply impossible to design a Programming Language which can express all problems equally well. So, having some Design Patterns in your code is perfectly fine, but you shouldn't have many of them and you definitely shouldn't have any Patterns in your core business logic. That's a sign that you chose the wrong programming language and no pattern can fix that.
Here's an example: in assembly programming, having a parametric piece of behavior shared between different parts of the program is a commonly occuring design problem. And there is a design pattern that solves that problem: it's called a Subroutine. But in a different language, and in fact in pretty much all modern languages, subroutines (sometimes called procedures, functions, methods, routines, subs) are built right into the language. They aren't a Pattern, they're just there and nobody even thinks about them anymore. So, if you have just one or two subroutines in your code, that's fine. But if you have many of them, assembly is probably not the right choice.
Some other examples: In a prototype-based OO language, the Prototype Pattern is built in. In a language with multiple dispatch, the Visitor Pattern is built in. In Ruby, there are no constructors, you always use Factory Methods without thinking about it. In delegation-based OO languages, the Decorator Pattern is built in. In languages with higher-order procedures, the Iterator Pattern is built in. In languages without mutable state, the Iterator Pattern is actually an Antipattern.
As everyone has said they are effectively "Blue - Prints" for solving common problems. Many developers use them on a day to day basis, without ever knowing they are using defined "patterns" as many of them jsut "make sense"
Unfortunatly far to many people, who would benefit from knowing these patterns, are oblivious to their existance.
Have a look at the following link for the GOF deffinitions
http://www.dofactory.com/Patterns/Patterns.aspx
Then look into Martin Fowlers Enterprise patterns and also Bob Martin`s SOLID principals (while these are not patterns per se, they are a good foundation to follow.