Lecture 4. Design Patterns

Transcription

1 Lecture 4 Design Patterns In the last three lectures we have focused on the design stage of the software systems development life cycle and described the artefacts (models) that have to be produced to describe a system from various design perspectives. We also introduced the notations offered by UML to specify these artefacts. This lecture is also concerned with the design stage of the software development life cycle but focuses on a slightly different issue. It is concerned with the application of pre-existing, codified solutions, known as design patterns, to known frequently re-occurring software design problems. Spanoudakis 4-1

2 Objectives To introduce the role of patterns in software systems design To present some frequently used structural and behavioural patterns for object oriented design The objectives of the lecture are: (a) to introduce the role of patterns in software systems design and (b) present some frequently used patterns for object oriented design along with examples of their application. Spanoudakis 4-2

3 Lecture Overview introduction to patterns object patterns elements of object patterns types of object patterns structural patterns behavioural patterns pros and cons of design patterns The lecture starts by giving and discussing a general definition of patterns and object design patterns. It then identifies and discusses the essential ingredients of an object pattern, and introduces three types of object patterns, namely the creational, structured and behavioural patterns. The lecture presents 3 structural and 3 behavioural patterns and then discusses the advantages and drawbacks of using patterns in software design. The patterns presented in the lecture have been proposed and extensively discussed by Gamma, Helm, Johnson and Vlissides in [GHJV95]. Our presentation is based on their presentation but uses the UML models to codify the solution realised by each of the patterns and demonstrates the use of some of these patterns using different examples. Spanoudakis 4-3

4 Design patterns A definition of patterns in classical architectural design: Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. [Christopher Alexander] The idea of pattern reuse is not new. Alexander, often seen as the father figure of patterns, was promoting the use of patterns for architectural design of buildings in the 1960s and 1970s (Alexander 1977). Spanoudakis 4-4

5 Object Design Patterns A pattern is a configuration of communicating objects and classes that can be customised to solve instances of the same general design problem in different contexts (based on [GHJV95]). object object pattern Patterns: facilitate component-based s/w development increase the size of the reusable units mirror human expertise are used in other disciplines architectural patterns/languages (Alexander, 1977) case-based reasoning One of the most-often heard benefits of object-orientation is reuse. Due to the application of classes and encapsulation it is possible to reuse different artefacts such as source code or even whole parts of system designs. The current focus for reuse is the object. For example in a library circulation control system one of the most important class objects is the borrowed-item. The borrowed item is also an important part of other library systems such as stock control, security and repairing. Therefore this class is reusable during the construction of class diagrams for stock control, security sensing and management of stock repairs. Furthermore this class has the potential to be reused during the analysis of other library systems in individual departments, other universities and so on. However, reuse of such small components does not provide us with great benefits and, as a result, has not yet changed the way in which we do object-oriented analysis and develop software. What is really desirable is to increase the granularity of the reusable component, that is to reuse groups of interrelated classes rather than individual classes. This new component is the object pattern. A pattern is a configuration of communicating objects and classes that can be customised to solve instances of the same general design problem in different contexts [GHJV95]. Software engineers have taken longer to cotton on to the usefulness of patterns. One of the intrinsic attractions of pattern reuse is that it mirrors human expertise, and in particular how experienced systems developers reuse mental schemata (a cognitive pattern) when they recognize a problem similar to one solved previously. This recent interest in patterns is found in other disciplines. For example, in applied artificial intelligence there has been a move away from the use of general rule bases towards casebased reasoning, where the main purpose of the system is to store solutions to old problems and exploit these solutions when a similar problem is encountered. These solutions are often quite large, and include a large amount of contextual information which makes the solution semantically rich. Such contextual information is also essential in reuse of large object patterns. Spanoudakis 4-5

6 Elements of object patterns In general, a pattern has four essential elements: a name - an identifier that conveys the essence of the pattern a problem - a general description of the problems and contexts in which the pattern can be applied a solution - the components of the pattern, their relationships, responsibilities and collaborations consequences - the results and trade-offs of applying the pattern There seems to be a consensus amongst software researchers and practitioners about the basic elements of any software pattern: each pattern has a name, can be applied to a certain kind of problems, provides a specific solution to this kind of problems and its application has certain consequences. The name of a pattern should be carefully chosen to make it easier to understand both the problem that the pattern is meant to solve and the way in which it solves it. As it will soon become evident, killing two birds with the same stone is rather difficult in this case. This is why a pattern should also incorporate separate descriptions of both its problem and its solution. The description of the problem in a pattern must clearly specify the abstract features of the situations that the pattern can be applied to as well as any contextual factors that affect this application. Describing the problem at the right level of abstraction and granularity is perhaps the most critical factor for the success of the pattern. An inadequate description might inhibit the ability of software developers to recognise a situation as one where the pattern could be applied to. The description of the solution in a pattern should indicate the main components of the pattern, the relationships between these components and their collaborations. Like the problem, the solution has to be described in abstract terms. A pattern should also describe the consequences (i.e. the trade-offs) of its application. These include time and space trade offs as well as the implications that the pattern might have to the maintainability and extensibility of the system. It has to be appreciated that the description of consequences is valuable only if it makes it possible to understand and evaluate the pros and cons of applying the pattern. Spanoudakis 4-6

7 Types of Object Patterns Creational patterns that deal with the process of object creation. Structural patterns that deal with composition of classes or objects to realise new functionality. Behavioural patterns that deal with object interactions and distribute responsibility. Software design patterns can be classified into categories according to various criteria including the kind of the problems they apply to, the kind of the objects they incorporate, the essence of the solution they encode, or the general design philosophy they realise. A classification might be useful especially if it makes it easier for developers to locate the pattern(s) that can be applied in specific situations. The patterns discussed in the rest of this lecture have been grouped and classified according to their purpose as suggested in [GHJV95]. This classification criterion is concerned with what the pattern does. Depending on their purpose patterns can be distinguished into creational, structural and behavioural patterns [GHJV95]. Creational patterns are concerned with the process of creating and initialising objects. Structural patterns are concerned with ways of composing objects to achieve certain kinds behaviour. Behavioural patterns are concerned with the distribution of responsibilities among interacting objects. In the rest of this lecture, we present specific structural and behavioural patterns proposed by Gamma. The patterns presented here are not the only ones proposed. More patterns as well as a more detailed discussion of the patterns presented may be found in Gamma s book. Note that our presentation uses the UML notation to specify the solution of each pattern. Spanoudakis 4-7

8 Structural Patterns: Proxy problem: control access to an object (object on demand, smart pointers) solution: IF THEN rs. AbstractSubject RealSubject rs 1..1 SubjectProxy 0..n components: AbstractSubject defines a common interface for a subject and its proxy RealSubject the object that will be controlled (represented) by the proxy SubjectProxy the representative of the real subject that controls the access to it (its operations); it maintains a reference to the real subject The first design pattern that we discuss is called Proxy. Proxy is a structural pattern that can be used in cases where it is necessary to provide a substitute for another object and/or control access to it. This might be necessary when the real object is stored in a different address space or when it is expensive to create and maintain and therefore it should be available only on demand. Providing a proxy is also useful in cases where the real object has to be protected and accessed in different ways by different kinds of objects. The proxy in this case acts as an access controller. The proxy pattern has three components: RealSubject This is the class of the objects that the need proxies. This class defines and implements the operations that these objects normally have. SubjectProxy This is the class representing the objects acting as proxies. This class establishes the structure for maintaining references from the proxies to the real subjects (see the association end rs in the slide), and implements the interface that the real subject and the proxy have in common (defined by the abstract subject). AbstractSubject This is a class that defines the common interface for the real subject and the subject proxy. This interface guarantees that the subject proxy can be used anywhere that the real subject is expected. Note that the way in which the subject proxy implements the interface it has in common with the real subject depends on the actual problem that the proxy pattern wants to solve. Thus, if the proxy is needed to control the access to the real object, it has to check whether the objects which request an operation from this object have the right to do it. If the proxy is needed to create an expensive object (e.g. a postcript image) on demand, it will probably have to cache information about this object to postpone access to it. If a proxy is needed to stand for an object stored in a different address space it will probably have to encode a request (along with its arguments) before sending it to the real object. An example of using the proxy pattern to substitute for expensive objects is given in the next slide. Spanoudakis 4-8

9 Proxy Example and Consequences AbstractImage extent: Extent drawimage() IF rs ==nil THEN rs = loadimage(imf); END IF rs.drawimage(); PS_Image drawimage() rs n PSImageProxy imf: FilePointer drawimage() loadimage(i:filepointer) consequences indirection when accessing the real subject, controlled access possibility for optimisations, record keeping hiding of objects residing in different address spaces performance loss As an example of using the proxy pattern, consider a text editor which supports the embedding of large postcript images in text documents. Postcript images are not only expensive to save but also quite slow to manipulate. Thus if they were physically embedded within a document they would make frequent operations on it, such as opening and scrolling through the contents of the document, quite slow to execute. Certainly, a document must always know the extend of an image in it (i.e. its width and height) and maintain a reference to the area which this image covers. However, it does not have to include the actual image data in it all the time. Only when a request for an image operation is received (for example a request to draw the image) the actual data of the image should be loaded in the document. Having a proxy for the postcript image solves this problem. As shown in the slide, a postcript image proxy knows the extent (see the attribute extent of PSImageProxy) of the image it represents and creates it on demand: when for instance the image has to be drawn (see operations drawimage() in PSImageProxy). Proxies may be used to optimise the access to the objects they represent in various ways. They may for instance load them in memory only when they are first referenced. They may also do some housekeeping for them such as maintaining a reference count, or locking them to ensure that no two objects may try to modify them simultaneously and so on. Proxy is the last structural pattern we consider in this lecture. The patterns that we will look at in the following are behavioural patterns. Spanoudakis 4-9

10 Structural patterns: Decorator problem: add behaviour to individual objects (not classes) dynamically solution: decorate them component. Component component 1..1 ConcreteComponent Decorator ) components ExtraBehavior() super. Decorator Abstract class that defines the interface of the objects to be decorated ConcreteDecorator Defines and implements the behaviour that constitutes the decoration ConcreteComponent The class of the objects to be decorated ConcreteDecorator ExtraBehaviour() The next pattern we discuss is called decorator. The decorator pattern that can be used to attach responsibilities and behaviour to individual objects (rather than entire classes) dynamically and detach these responsibilities from the object at some later point if required. The way in which the pattern resolves this problem is to enclose an object into another object which acts as its a decorator. The decorator conforms to the interface of the object it decorates. Thus, it may be used as a substitute for this object wherever required. Note, however, that the decorator might change the implementation of some the operations of the decorated object. The decorator pattern has four basic components: The Component The component class defines the operations that may be attached to an object by different kinds of decorators. The Decorator The decorator class establishes the structure for enclosing the objects to be decorated and forwards the requests that the decorators receive on behalf of the enclosed objects to these objects. The Concrete Decorators The concrete decorator types alter the implementation of the operations of the decorated objects as required. The Concrete Components The concrete component types represent the types of the objects that can be decorated. The decorator pattern makes it possible to attach decorators to decorators as well as component objects (note that the association role component is attached to Component rather than ConcreteComponent). Thus, it is possible to decorate the same object in successive layers using different decorators. In the next slide we give an example of using the decorator pattern. Spanoudakis 4-10

11 Decorator Example and Consequences component.getleave() Academic getleave() component 1..1 Lecturer Professor AdminRole getleave(): Integer return (ceiling(1.2* super.getleave()) HeadOfDepartment getleave(): Integer consequences: dynamic attachments and removals of behaviour avoids proliferation of classes (why?) problems with object identity As an example of cases where the decorator pattern is useful, consider the case of university academics who may, at different periods of their career, be acting as heads of departments. The extra responsibilities and the modified behaviours implied by these administrative roles can be modeled using an abstract decorator class called AdminRole. Suppose, for instance, that when an academic undertakes an administrative role his/her annual entitlement of leave is increased and that different administrative roles result in different increments to the annual leave. More specifically, suppose that heads of departments are entitled to one day more for every five days of leave that they would normally get. To introduce these changes we need to override the operation which computes the value of the annual leave entitlement in the class Academic in both the abstract decorator class AdminRole and the concrete decorator class HeadOfDepartment. In AdminRole we need to make sure that the object which will be used to decorate an academic with an administrative role will refer to its actual component to get the value of the attribute leave (see component.getleave()). In the concrete decorator class (i.e. HeadOfDepartment), the operation getleave will be refined so as to calculate and return the leave resulting after increasing the normal leave according to the role. In any case this will require to get the value of the attribute leave of the decorated object (see super.getleave()). The main benefit from using the decorator pattern is the flexibility of attaching responsibilities to and removing responsibilities from normal objects by using decorating objects. This also avoids the proliferation of classes in the system. In our example, for instance, it is not necessary to create special classes to represent heads of department who are lecturers and heads of department who are professors). The drawback of using decorators is that we can no longer rely on object identifiers to check the equality of objects (the decorating object has a different identifier from the object it decorates although it acts as a surrogate of it). Also if the decorator is meant to behave exactly as the decorated objects then the operations defined for the class of the decorated object will have to be defined in the concrete decorator class and forward the relevant requests to the component. Spanoudakis 4-11

12 Structural patterns: Composite problem: compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions uniformly. solution: forall g in Children g. Component LeafA LeafB Composite components: component declares a common interface for the composite and component classes it generalises (it might also implement part of this interface) composite leafs Add(Component)_ Remove(Component) maintains references to component objects, expands and implements the interface of composite objects (including component related operations) implement operations in component type specific ways The next pattern we present is called Composite. This pattern can be used to create composite objects composed of different kinds of objects which, despite being different in many respects, have some operations in common with each other as well as with the composite. For instance, the composite pattern is quite useful in representing and manipulating graphs whose nodes might be primitive objects or sub-graphs of objects, as well as in representing and manipulating graphics consisting of heterogeneous kinds of graphical elements (e.g. circles, lines, square boxes etc). Composite has three kinds of components: the Component The component class declares the operations that the component and the composite objects in the structure have in common (for example an operation which retrieves the parent of an object in the structure). This class may also provide the default implementations of these operations. the Composite The composite class establishes the structure by which the composite objects can maintain references to their components. It also declares and implements the operations required for the composite objects (for example operations to retrieve the direct children and the transitive closure of the children of composite objects). the Concrete Components The concrete component classes represent the different kinds of the primitive objects in the composition. They also define and implement the behaviour of these objects. In the next slide we give an example of using the composite pattern. Spanoudakis 4-12

13 Composite: Example & Consequences Component paint(graphic g) Add(Graphic) Remove(Graphic) GetChild(int) forall g in component g.paint() self.paint() component Canvas Button MyContainer paint(graphic g) paint(graphic g) add(component g) remove(component g) getcomponents() add g to components consequences: defines class hierarchies consisting of primitive objects and composite objects extensible, heterogeneous hierarchies of primitive and composite objects simple client due to uniform treatment of constituent objects hard to restrict the types of the components of the composite The composite pattern has been used in Java to construct hierarchies of objects which have graphical representations, can be displayed on the screen, and interact with the user while being assembled in composite containers. The example shown in the slide presents a hierarchy of this kind modeled based on the Java GUI library. Java provides an abstract class called Component to represent all these objects. Component introduces a method called paint which is used to paint the contents of a component when the component is first being drawn or when it has to be redrawn. The Java class Container plays the role of the composite in the pattern. In Java, an instance of this class is an object that can contain other AWT components. Container overrides the method paint in class Component. Paint in Container forwards the paint request to the lightweight components included in the container. Some of the types of component objects, such as Canvas (i.e. a blank rectangular area of the screen onto which the application can draw or from which the application can trap input events from the user), override the method paint. Other, like Button, do not. Canvas needs to override paint because it has to redraw its rectangle in the background colour. Note that Canvas and Button will normally be further specialised by applications needing to introduce buttons and canvasses with special behaviour. The application classes specialising Button and Canvas might need to re-implement paint. The composite pattern allows the composition of heterogeneous, primitive objects into more complex objects which can then be composed into more complex objects and so on. The clients can treat the resulting object structures and the individual objects uniformly. For instance, they can ask the structure as well as any of its constituents to print itself using the same operator. The resulting structures can easily be extended to incorporate components of different kinds but this flexibility has to be exercised consciously. Spanoudakis 4-13

14 Behavioural Patterns: Observer problem: ensure that a set of objects which all depend on the same object update their internal state consistently when this object changes its own internal state 60% 50% 40% 30% 20% 10% Series1 a b c 0% a b c a=50% b=30% c=20% The key objects are subject and observer. A subject may have any number of dependent observers. All observers are notified whenever the subject undergoes a change in state. In response, each observer will query the subject to synchronise its state with the subject s state. The next behavioural pattern we consider is called observer. This pattern can be used to establish dependency links between an object X and a set of other objects which need to observe the changes of the internal state of X and update their own internal states accordingly. Consider for a instance a chart which depicts a series of data. If the data change then the chart should also change to reflect them (the shape of the chart depends on the data). The chart must be notified of any change in the data to be able to redraw itself. The observer pattern describes how to establish dependencies like this and the interaction between the objects to be observed and the observers. Spanoudakis 4-14

15 Observer: solution & components solution: Observer modify() observer observable Subject add(o: Observer) delete(o: Observer) notify() For all o in observer do {o.modify()} ConcreteObserver observerstate modify() components: observerstate := observable.getstate() ConcreteSubject state getstate() setstate() Subject the object to be observed. Knows its observers. provides an interface for attaching and detaching observers Observer defines the updating interface for all the observers (modify()) ConcreteSubject stores state of interest to concrete observers. Notifies its observers when state changes. ConcreteObserver maintains a reference to a concrete subject, updates its state consistently with the subject, stores state that should stay consistent with the subject s The pattern has four key components: The Observable Observable is the abstract class of the objects that must be observed and provides the structure for establishing the connections between an observable and the objects that will observe it. The observable also defines and implements operations for attaching and detaching observers from an object (see operations add(o:observer) and delete(o:observer)), and operations for notifying changes that have occurred to the internal state of an observable (see operation notify()) Concrete Observable This is a class representing the objects which must be observed. The concrete observable stores the state which is of interest to the observers and provides operations for setting and fetching this state (see operations setstate() and getstate()). Observer This is an abstract class representing the objects which need to observe other objects. The observer class defines operations for updating the internal state of the observing objects when the internal state of the object they observe changes (see operation modify()). Concrete Observer This is the class representing the objects which must observe other objects. The concrete observer class defines the part of the state of the observers that should be consistent with the state of the observables and implements the operations which update this part. In the next slide we show how the observer pattern can be used to establish the dependencies required in the case of the chart and the series of data. Spanoudakis 4-15

16 Observer: example and consequences example: OCHLPriceTable notify() getclprices() gethlcprices() observer CPriceChart cprices: PriceList modify() display() PriceChart modify() observer HLCPriceChart hprices: PriceList cprices: PriceList modify() display() :OCHLPriceTable :CPriceChart :HLCPriceChart setprice() notify() modify() getclprices() display() modify() gethlcprices() display() sequence diagram consequences: flexibility in varying observables and observers support for broadcast communication unexpected updates Suppose that within a document we have a table of stock prices and two charts depicting these prices. The table includes the closing, higher and lower intra-day prices of each stock. One of the charts shows only the closing prices while the other shows all the three prices for each trading day. It would certainly be useful to have the charts updating themselves when the prices in the price table change. The structure shown in the slide makes it possible. The classes CPriceChart and HLCPriceChart, which represent the closing and the high-low-closing price charts respectively, have been attached as concrete observers to the class OCHLPriceTable (i.e. a concrete observable). When the prices in the table change, OCHLPriceTable sends the message notify() to itself and as a result the message modify() to each of its observers. Each of the observers responds to this message in a different way. As shown in the sequence diagram, CPriceChart gets only the new closing prices and re-displays itself while HLCPriceChart gets the new closing as well as the new high and low intra-day prices and then re-displays itself. The observer pattern makes it possible to connect observers and observables which exist at different layers of abstraction within a system. For instance, it is possible to make a low level graphical user-interface object (e.g. a scrollable list) an observer of an object which is an instance of a domain entity class. Furthermore, the pattern supports effectively broadcast communication. The observable does not need to specify the recipients of a notification. By sending a notification to the objects connected to its association role observer, it makes sure that all the objects which have been registered as its own observers will receive the notification (note that the observers of an object may change dynamically). In some cases, the observer may also issue a request to update the state of the observable. This might lead to an unexpected cascade of changes to other observers (and their dependent objects), which may not be desirable and certainly hard to track down. The observer pattern has been realised in many programming languages (e.g. Smalltalk, Java) and user interface toolkits (e.g. Andrew). Java provides an abstract class for observable objects, called Observable, and an abstract interface for observer objects called Observer. These classes correspond directly to the classes Observable and Observer of the pattern as discussed here and can be specialised to create structures realising it. Spanoudakis 4-16

17 Behavioural patterns: Command problem: issue a request without knowing who is going to execute it or what parameters should be provided with it, or which might need to be cancelled solution: Client Invoker Command Exec() Receiver receiver <<creates>> ConcreteCommand state Exec() Receiver. components: Command defines the interface for executing any command (Exec()) ConcreteCommand establishes the association between a Receiver and an operation implements execute by invoking the corresponding operations on Receiver Invoker asks the command to carry out the request Client creates a concrete command object and sets its receiver Another behavioural pattern we consider in this lecture is a pattern known as command. This pattern can be used in cases where an operation request may need to be parameterised or cancelled before committing its effects, or where the object issuing the request is not aware of the object that will execute it or the information that should be provided along with the request. A solution to these problems is to model the requests as objects following the command pattern. This pattern has four basic components: i. Command This is a class that defines the interface for executing an operation. ii. ConcreteCommand This is a class that establishes the structure for maintaining a reference to the actual receiver of the operation and implements the interface for executing it. This implementation has to forward the request to the receiver at some point. iii. Receiver This is a class that implements and executes the operation requested. iv. Invoker This is a class that issues the request by asking an instance of the class ConcreteCommand to execute it. In the following slide we give an example of using the command pattern. Spanoudakis 4-17

18 Command: example and consequences example: receiver DBHandler invoker update(oval:string, nval:string) DatabaseMenu receiver displays command UpdateRequest oldvalue: String newvalue: String Exec() :DatabaseMenu :Update :DBHandler Exec() update(oldvalue,newvalue) sequence diagram consequences: decoupling of operation invocation from operation execution easy to add new commands, and have complex commands commands become first-class objects (can be used as any other object) commands become more expensive to execute As an example of using the command pattern, consider a system where a database updating request is issued by picking up a relevant option from one of the menus of the system. As shown in the slide this system has a class, called DatabaseMenu, which implements the menu that can be used to issue requests for updating the database. The update requests are to be sent to the class DBHandler that represents the database server. To avoid tight coupling in the design of the system, the menu class should not be associated with the database handler. Note also that different update requests can be represented by filling up slots of a general template that specifies which objects need to be updated and how they should be updated. Furthermore, an update request might need to be cancelled if something goes wrong during the transaction. A design solution which eliminates the association between the menu and the database handler, parameterises the update request and makes it possible to reverse the effects of an update is shown in the slide. The class UpdateRequest has been created to represent update requests. This class is connected to the database server (see role receiver). Each newly created instance of it asks the user to specify the arguments of his/her update request (see the attributes oldvalue and newvalue). Once the parameters of the request have been collected the instance forwards the request to the server. Furthermore, it can store the state of the part of the database affected by the update and use it to reverse its effects if required. The structure replicates the command pattern with DBHandler playing the role of the receiver, UpdateRequest playing the role of the concrete command, and DatabaseMenu playing the role of the invoker. The command pattern decouples the object which requests an operation from the object that executes it (low coupling, normalised design); makes it easy to add new commands and create complex commands (i.e. commands incorporating parts that have to be executed by different objects); and makes commands first-class objects that can be manipulated like any other object (for instance they have their own internal state that may be used to reverse their effects). However, all these benefits arise only at the expense of requiring more messages between objects to execute operations. Spanoudakis 4-18

19 Pros and cons of patterns design patterns are useful because they provide general solutions with known trade-offs to common software design problems can be used to make explicit the philosophy of a design team can be used as a design documentation tool what makes the application of patterns difficult: complexity of patterns (name, problem, essence of solution, training) difficulty in recalling or locating a pattern (better classification, pattern languages, tool support) The availability of standard general solutions, which have well understood trade offs, to known frequently occurring problems characterises mature engineering disciplines like mechanical and electrical engineering. In these disciplines, designers instead of designing their artefacts from scratch by applying primitive scientific laws, tend to re-use standard designs with successful track records. Software engineers have tried, for quite a long time to advance their discipline to a similar level but not as successfully as other kinds of engineers. This might be due to the complexity and flexibility of software systems which makes it difficult to identify and abstract the salient characteristics of applied solutions. Nevertheless, software engineers have not been completely unsuccessful. Since the mid nineties, they have started encoding valuable solutions to known software design problems. Some of these solutions have been presented in this lecture in the form of patterns. As in other disciplines, the main benefit arising from the use of patterns is that software design does not have to start from scratch. Note however that this is not the only benefit of patterns. Software design patterns are also useful because they can be used to document fragments of a design in standard ways and thus make it easier to understand them. It has also been observed that the systematic use of design patterns by a design team helps the team to establish a common design philosophy, make it explicit and absorb new members more smoothly. However, it has to be appreciated that the application of patterns is not always as easy as it may seem. The main inhibitor to pattern application seems to be the inability to identify the pattern required for a given problem. This may have to do with the complexity of the pattern itself or the inability to realise a given problem as an instance of the problem to which the pattern applies. Clearly, the way in which the main components of a pattern have been described affects the likelihood of using it. Research over the last few years in this area has been focused on the development of languages for specifying, classifying and interrelating patterns as well as on tools to support the retrieval and customisation of general patterns to specific design problems. This research has delivered solutions which work for small scale patterns but it still has to address issues like the integration of patterns into more general frameworks as well as the effective support of reuse of coarse as opposed to fine-grain patterns. Spanoudakis 4-19

20 Summary patterns in OO software engineering main elements of patterns types of patterns creational structural behavioural pros and cons of patterns Our objective in this lecture was to introduce rather than discuss exhaustively design patterns. We presented a definition of object patterns; identified the basic elements of a pattern (the problem it addresses, the name it has, the solution it provides, and the consequences that its application is known to have), and distinguished between creational, structural and behavioural patterns. Then, we presented some useful design structural and behavioural patterns based on the presentation of these patterns in [GHJV95]. Finally, we discussed the advantages which arise from using patterns as well as the factors which may inhibit their use. It has to be appreciated that there are more patterns than those presented in this lecture. These patterns are concerned not only with the design of software but also with general object modeling problems, the software development process itself, or even with the management and allocation of human resources in the software development process. REFERENCES: [GHJV95] Gamma E., Helm R., Johnson R., Vlissides J.: Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley, 1995, ISBN [Alexander 1977] Alexander C.: A Pattern Language: Towns/Buildings/Construction, 1977, Oxford University Press [CACM 1995] Communications of the ACM: Software Patterns, Vol. 39, No 10, October 1996 Spanoudakis 4-20