Design Patterns-Software Engineering-Lecture 19 Slides-Computer Science, Slides of Software Engineering

Download Design Patterns-Software Engineering-Lecture 19 Slides-Computer Science and more Slides Software Engineering in PDF only on Docsity!

LECTURE 19: DESIGN PATTERNS

Software Engineering

1 Introduction

• Recall that one goal of software engineering is reuse: instead of designing and implementing all software from scratch, make use of existing, developed software.
• Design patterns are about reuse in design.
• The idea is that certain stereotypical design problems arise again and again.
• Rather than develop solutions anew every time we are presented with a problem, we can make use of design patterns that others have used.
• We will look at the following design patterns: - interfaces & templates; - observers; - proxies.

• One possibility: define a class Shape, with a default method area(), and get each sub-class (Triangle, Square,... ) to overwrite this method. But what if the method is not overwritten?
• Solution is to implement an interface for shapes.
• The interface a number of methods, without providing an implementation for them.
• Any class that implements the interface must provide an implementation for these methods.

• Here is the interface for Shapes:

public interface Shape { public float area() ; } // end interface Shape

• And here is how we state that Rectangle implements the Shape interface: public class Rectangle implements Shape { ... public float area() { return (float)(width * height); } ... } // end class Rectangle
• Similarly for Circles:

public class Circle implements Shape { ... public float area() { return Math.PI * (radius * radius); } ... } // end class Circle

• Interfaces are thus like certificates, which say “I provide these services”.
• You can’t make an instance of an interface:

Shape s = new Shape(); // ERROR!

2.1 Abstract Methods & Classes

• With interfaces, the entire functionality of the interface is left unspecified.
• But suppose you want to provide some of the functionality of a class, but leave some of it unspecified.
• Use abstract methods.

public abstract class Shape { public abstract float area () ; }

• As with interfaces, you can’t make an instance of an abstract class directly. You must sub-class it and provide an implementation for the abstract methods. public class Rectangle extends Shape { ... public float area() { return (float)(width * height); } ... } // end class Rectangle

3 Observers

• Suppose a collection of objects (observers) all want to monitor a particular object (subject), and be notified when a particular event happens within this object.
• EXAMPLE. A collection of applications (word processors, spreadsheets... ) want to know when a printer handled by a Printer object becomes available.
• Bad solution:

Each observer repeatedly polls the subject to see if event has occurred.

• Better solution:

Subject notifies observers when the event occurs.

1. Subject s and observer objects o1,... on are created.
2. Each observer oi invokes register method on subject, passing itself as an argument:

s.register(this);

3. The register method causes the object passed as a parameter to be added to a list of observers of the subject. (This list is held within the subject.)
4. When the relevant event occurs inside s, the object s gets the list of registered observers and for each object oi, invokes a method notify on oi, passing itself as an argument.

4 Proxies

• Particularly in distributed systems, it is useful for objects to “pretend” they are talking to objects that are actually distributed across the network.
• Standard method for doing this:

proxy objects

• In distributed object systems, a proxy object p to an ordinary object o provides all the methods that o does. When a method m is invoked on p, by object q, the proxy p communicates across the network to a program that is managing o. This program then invokes the method m on o, collects any return parameters, and sends them back to p. Then p returns the arguments to q. As far as q is concerned, p actually executed the method itself.
• Clients need not be aware of where objects actually are.