design patterns are like magic beans that, if sprinkled on your code, will make it "better". like XML, the more of them you use, the "better" your application will be, and one can quantify how good a programmer is by the number of design patterns he "knows". the ultimate programmer is the one who can reel off the names and descriptions of all 23 design patterns known to man
the above is, of course, complete nonsense. design patterns are recurring themes that are known to crop up in software design over and over again. just as most builders the world over eventually worked out that a foundation followed by walls followed by a roof is a good design for a house, software designers have realised that they often solve problems in a similar way. some people describe design patterns as "idea reuse". the basic premise is that, no matter what problem you have to solve in software, somebody else has probably already solved it. a pattern is this solution distilled into a generalized idea other people can apply. people have made all of the above mistakes when thinking about patterns, please try and avoid those mistakes!