Describing object-oriented design patterns

Describing object-oriented design patterns

In architectural terms, the evolution of the 'object concept‘ has been one of the major developments of the 1980s and 1990s. While our main discussion of this will be provided here. we have inevitably needed to consider some of its characteristics in earlier chapters, and in this chapter we again adopt the view that only those characteristics of specific relevance to the use of design patterns will be considered here. In brief, an 'object‘ can be viewed as being an evolutionary development of the concept of the abstract data type, that provides an abstraction of a part-solution that:

·          possesses a state which is encapsulated within the object;

·        exhibits behaviour in that it responds to external events;

·        possesses an identity (there may be more than one object of a given type); where the inspection/modification of its state can only be achieved through the use of those external

methods that are provided by the object as its interface to the outside world.

For the purposes of this chapter, the key features of an object are that it provides an abstraction of the part-solution, that it incorporates the notion of encapsulation of state information, and that it provides externally accessible methods. We should note one, some have argued that many ‗real-world‘ problems can themselves be modeled in terms of 'real-world‘ objects. Hence one approach to object-oriented design is to identify these real-world objects and develop a solution by providing corresponding implementation objects that model their behaviour. For most purposes, however, the design patterns community has concentrated on describing implementational objects provide reusable elements of solutions rather than on describing problem objects.

1. Their purpose. The purpose describes what a pattern is used for, and is usually described as being one of the following three types:

·        creational patterns are concerned with object creation;

·          structural patterns address the way in which classes or objects are composed;

·        behavioral patterns describe the way that classes or objects interact, and how responsibility is allocated between them.

2. Their scope. This describes whether the pattern is primarily one that addresses the use of classes or the use of objects (where we can regard classes as being the ‗templates‘ from which objects are instantiated). Most patterns deal with objects, and we will not attempt to discuss the use of class patterns in this book. In contrast, Buschmann et al. (1996) use a framework that is much more concerned with design hierarchy. Whereas the GoF focus upon design patterns Buschmann et al.

takes a wider view of pattern applicability, including for: n architectural style (architectural patterns relating to the form of the overall system);

·          design (design patterns that relate to the detailed form of subsystems);

·          programming (idioms that describe the broad structure of code).

For the case of design patterns, they adopt a scheme of grouping patterns under the following set of role-based headings.

·        Structural decomposition where patterns ‗support a suitable decomposition of subsystems and complex components into cooperating parts‘, with the term ‗structural‘ being used in a similar sense as by the GoF.

·        Organization of work which is concerned with component collaboration (a bit like the GoF‘s concept of ‗behaviour‘).

·          Access control describes patterns that ‗guard and control access to services or components‘,

which we can again recognize as a form of structural grouping.

·        Management where patterns address the organization of collections of objects (roughly structural again).

·        Communication which is concerned with (obviously) communication between system components.