Patterns are not the panacea of program design. They do not replace traditional object-oriented analysis techniques like CRC cards or use-case modeling. To use an architectural analogy, analysis lets you determine that your house needs 200 amps of electricity. Patterns let you determine how the wiring will be installed.
Patterns do help you think about the problems you may encounter while designing a system. Therefore, a generic, pattern-based solution isoften more robust than a solution designed by one individual to solve a specific problem.
Given the number of design patterns in common use (as well as many more being invented and discovered almost daily) it can sometimes be hard to choose the pattern that suits your needs.
The first thing you should decide is whether the problem is fundamentally creational, structural, or behavioral. Some problems, of course, have aspects of two or even three, and may require you to mix and match patterns.

The most notable aspect of this site is the manner in which the coverage of design patterns is interwoven with the remainder of the material.
For example,

1. Swing containers and components motivate the COMPOSITE pattern.
2. Swing scroll bars motivate the DECORATOR pattern, and Swing borders are examined as a missed opportunity for that pattern.
3. Java streams give a second example of the DECORATOR pattern. Seeing the pattern used in two superficially different ways greatly clarifies the pattern concept.

Without memorable examples, design patterns are just words. In order to visualize design patterns, this website uses examples from graphical user interface programming. Students will remember how a component is decorated by scroll bars, and how layout managers carry out different strategies. (A small and carefully selected subset of Swing is used for this purpose.)

This website discusses the design and implementation of computer programs from the object-oriented point of view. Although much of what we say remains valid for large projects, there are added complexities with large projects that we will not address here. Programming tasks originate from the desire to solve a particular problem. The task may be simple, such as writing a program that generates and formats a report, or complicated, such as writing a word processor. The end product is a working program. To this end, it is a common practice to break up the software development process into three phases:

1. Analysis
2. Design
3. Implementation