Designing re-usable object-oriented software involves recognising the right objects in a problem domain, refining them into classes with defined inheritance hierarchies and interfaces, and establishing their key relationships. This decomposition exercise is complicated by the many factors that need to be taken into consideration, e.g. granularity, dependency, flexibility, performance, re-usability, etc.

Design patterns provide templates that demonstrate good design practice. They identify key aspects of common design structures that are useful for creating re-usable object-oriented software. Each design pattern is a solution to a particular, but recurring object-oriented problem. It describes when the solution can be applied, taking into account other design constraints, and what the consequences and trade-offs of its use are. The solution identifies the participating classes and instances, their roles and collaborations, and the distribution of responsibilities.

Design patterns are based on practical solutions that have been successfully implemented over and over again using all the mainstream object-oriented languages. Used correctly, they have been proven to offer the following benefits:

• Successful designs and architectures can be re-used to leverage previous designs and prior experience.
• The need to re-design due to unexpected changes is minimised, thus making a system more robust.
• Less-obvious abstractions can be identified making a system more flexible, elegant, and re-usable.
• Dependencies are reduced and the extensibility of class hierarchies can be enhanced using effective composition.
• Communication is improved by using a common language that describes the architecture and design.

Use design patterns sensibly

Design patterns should not be applied indiscriminately. When over-applied they can do more harm than good.

The benefits of using design patterns do come at a cost. Often the achieved flexibility and variability introduces additional levels of indirection, which can increase the complexity of a design and incur performance degradation. There is always a trade-off to consider - a design pattern should only be applied when the flexibility it affords is actually required.