If you've got some experience in OOP, you probably know of some ways to make your classes interact that work well, and others that will become cumbersome and inefficient.
For example, some developers build a scene graph in their games that stores all the visuals of a given scene. This scene graph consists of nodes that can be childs to each other. Any visual is then derived from a common node class that allows it to have children of its own.
Another example: Often, game programmers create a centralized resource management system that has one global instance through which all game objects can ask for the resources they need (textures, sounds, meshes, ...).
Such interactions between classes (from the example: class that can store childs of its own type and class that has a single, global instance) surface in any OOP software project. Sometimes they are less visible, sometimes the design is even lost and large numbers of classes interact with each other in random, but there are some setups which tend to appear quite often because they work well.
Someone then had the idea to identify these well-working interaction schemes and give them names. This is what design-patterns are. They give you a number of well-working methods to let your classes interact with each other that are elegant, maintainable and make development a breeze.
I'm planning on dedicating an entire section of this site to design patterns (didn't we have this very same sentence in the Agile Programming page, too? ;)). Please be patient.
If you can't wait, just google Design Patterns, you should discover a bazillion sites with resources to the subject.