How to use design patterns during development?

How to use design patterns during development?

Experienced programmers draw on half-remembered memories of software framework that they have used themselves or seen used in the past. An example of a simple programming pattern is the design of a program to find the largest number in an array of numbers. The simplest algorithm uses a variable to record the largest value that has yet been encountered.
The program starts at the beginning of the array and proceeds item by item, examining each number, updating this variable as necessary:

largest = list[0]
index = 0
while index <= list. size() do
if list[index] > largest then
largest = list[index]
end if
index = index + 1
end while

This is clearly a small piece of program that is easily constructed by any experienced programmer, but to inexperienced programmers, seeing this is something of a revelation. And once seen, the programmer never forgets it. Or at least the programmer remembers the idea of what is needed, rather than the detail. This is a software pattern. Over a period of time, experienced programmers build up a large repertoire of memories of programming patterns such as this one. A number of patterns have been identified, given names, cataloged and recorded in catalogs or books. These patterns are available for off-the-shelf use, just as classes are available in class libraries. Software engineering patterns are patterns on a larger scale than the simple program seen above. The established patterns specify the structure of useful software at the architectural level. In object-oriented development, this means structures expressed in terms of classes and their interrelationships. The strength of design patterns is that good design ideas are recorded, given a name, and explained with the aid of examples. This extends the vocabulary of software developers. It also extends the repertoire of ideas that they can use without reinventing the wheel. To make use of patterns, the software engineer needs some recollection of the standard patterns. This is obtained by browsing a patterns catalog prior to a project. The engineer thereby maintains some memory (perhaps only a partial recollection) of the patterns, then, during the early phase of software architectural design, the engineer realizes that one or more patterns may be useful. They then consult the catalog to confirm the appropriateness of the pattern and see exactly how to use it. The next step is to use the pattern as part of the design.

In summary the stages are:

1. Browse a design pattern catalog, to obtain some feel for the available patterns
2. Embark on a new design with an awareness of the patterns
3. Recognize the need for one of the established patterns
4. consult the catalog to check the applicability of the pattern
5. Use the catalog for information on the how to use the pattern
6. Use the pattern as part of the design.

As well as architectural structure, patterns are available for such domains as user interfaces, file systems and multithreading. Patterns are also provided for work as testing and project management. In order to use design patterns the programmer needs considerable experience and understanding of OOD and OOP. Just as there are patterns (which are valuable structures) so there are opposition-patterns, which are offensive structures. The reason for identifying and cataloguing opposition-patterns is to avoid them. We look at one such pattern. In this chapter we present a number of useful patterns and use the cyberspace invaders game as an example in explaining some of the patterns.