Patterns in the usage of classes and therir relationships occur many times in program designs. The pattersn have been abstracted and can be reused in a new design as long as the pattern can be recognized as appropriate.
Patterns are suggested solutions to general problems, not specific solutions to specific problems. The must be adapted to be used at all. Rarely can they be used unaltered.
Good patterns are as general as possible and be easy to understand. It should also have a name that is easy to remember. Most patterns can be represented using a UML class diagram. The "forces" that drive a pattern are the set of issues that the pattern addresses, its level of generality, and, ultimately, its usefulness. There are many pattern catalogs with many different patterns. What you use is a judgement call depending on the structure of your system (the problem) and its design (the solution).
Patterns embody not only the basic OO principles (abstraction, encapsulation, inheritance and polymorphism) but also design principles:
Common patterns and their class diagrams are:
Strategy: defines a family of algorithms, encapsulates each one and makes them interchangeable.
Observer: a one-to-many dependency between objects so that when one object changes state, all the dependent objects are notified and updated automatically
Decorator: Attach additonal responsibilities to an object dynamically.
Factory: defines an interface for creating objects, but lets subclasses decide which class to instantiate
Abstract factory: provides an interface for creating families of relalted or dependent objects without specifying their concrete classes.
Singleton: ensures that a class has only one instance, an provides a global point of access to it.
Command: encapsulates a request as an object, thereby letting you parameterize othe objects with different requests, and to support undoable operations.
Adapter: converts the interface of a class into another interface the client expects.
Facade: provides a unified interface to a set of interfaces in a subsystem.
Template: defines the skeleton of an algorithm in a method, deferring some steps to subclasses.
Iterator/composite: allows traversal of the elemetns of an aggregate without exposing the underlying implementation.
State: allows an object to alter its behavior when its internal state changes. The object will appear to change its class.
Proxy: provides a surrogate or placeholder for another object to control access to it.