Software Engineering Lecture 7 - Design Patterns

Agenda Short introduction to the assignment Small introduction to important terms What is a design pattern and why use them? Presentation of a few patterns Singleton Factory Method Abstract Factory

About the assignment Goal Task Learn about different patterns Learn how to apply patterns Task Read about the patterns Identify 3 patterns that are used in your project Describe how they are implemented

What is a design pattern? "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, NY 1977 He was an architect and said this about building patterns but it’s every bit as true about design patterns.

Why use design patterns? ”One way to measure the quality of an object-oriented system is to judge whether or not its developers have paid careful attention to the common collaborations among its objects. Focusing on such mechanisms during a system’s development yields an architecture that is smaller, simpler, and far more understandable than if these patterns are ignored.” -- Grady Booch Collaborations, structure, creations…

Why use design patterns? cont. Why use design patterns? Proven Reusable Expressive “Software entities should be open for extension but closed for modification” ”Program to an interface not an implementation” ”Favour composition over inheritance”

Four kinds of patterns Creational – Abstract Factory, Builder, Factory Method, Prototype, Singleton Structural – Adapter, Bridge, Composite, Decorator, Façade, Flyweight, Proxy Behavioral – Chain of Responsibility, Command, Interpreter, Iterator, Mediator, Memento, Observer, State, Strategy, Template Method, Visitor Software Architectural Patterns

Scenario

Alipes A platform encapsulating several different positioning-techniques One simple interface for all different techniques Keeps device specific implementation away from application developers

Singleton

Singleton -- problem Ensure only one instance of a class Defining everything static is a bad idea Not flexible Not encapsulated

Singleton -- solution Let a static method return itself Create if non-existing Singleton ensures only one instance Only requires one static method

Singleton -- UML Singleton Return uniqueInstance Underlined means static + Instance() : Singleton + SingletonOperation() + GetSingletonData() : singletonData + uniqueInstance singletonData

Singleton -- example Alipes example A server opens a port on the network Listens for commands on the opened port Can only have one instance of the server Use singleton

Singleton – example cont. 01. public Singleton { 02. // private instance 03. private static Singleton uniqueInstance; 04. 05. // private constructor 06. private Singleton() { 07. } 08. 09. // instantiation method 10. public static Singleton Instance() { 11. if (uniqueInstance == null) 12. uniqueInstance = new Singleton(); 13. return uniqueInstance; 14. } 15. ....

Singleton -- usage Consequences Controlled access to a sole entity Encapsulation Reduced name-space No global variables needed More flexible than class operations easier to change

Factory Method

Factory Method -- problem Create and maintain several components The class can’t anticipate the class of objects it must create Hardcoding which components to use is a bad idea Requires constant changing Not using a common interface is bad Makes the code hard to read

Factory method -- solution Define a common interface for the components Let subclasses decide which to instantiate Factory Method defers instantiation to subclasses

Factory Method -- UML Product Creator ConcreteProduct ConcreteCreator + FactoryMethod() : Product + AnOperation() ConcreteProduct ConcreteCreator + FactoryMethod() : ConcreteProduct

Factory Method - example Alipes example Several positining-tecniques Available positining services vary between devices Factory Method Create a common interface (PushPositionDevice) Implement support for a positioning-technique, implement the PushPositionDevice interface Let the factory instantiate the necessary positioning-devices

Factory Method – example cont. 01. public interface PushPositionDevice extends PositionDevice { 02. public void addPositionListener(PositionListener pl); 03. } 04. 05. public class DeviceManager implements PositionListener { 06. synchronized void loadAllDevices() { 07. String[] deviceClasses = getDevices(); 08. 09. for (int i=0; i < deviceClasses.length; i++) { 10. try { 11. Class c = Class.forName(deviceClasses[i]); 12. // open up the device 13. PushPositionDevice pd = (PushPositionDevice) c.newInstance(); 14. } 15. } catch (Exception err) { 16. } 17. // …} // …}

Factory method -- usage Consequences Makes dynamic architectures possible

Abstract Factory

Abstract Factory - Problem Ex: You want to be able to easily change the look-and-feel of your user interface (not hard coding it) Bad solution – Instantiating with concrete classes throughout the application: UnixWindow w = new UnixWindow();

Abstract Factory - Solution +CreateA(): AbstractA +CreateB(): AbstractB ConcreteFactory1 +CreateA(): A +CreateB(): B ConcreteFactory2 AbstractA A1 A2 AbstractB B1 B2 Client

Abstract Factory – Solution +CreateWindow(): AbstractWindow +CreateScrollbar(): AbstractScrollbar UnixFactory +CreateWindow(): UnixWindow +CreateScrollbar(): UnixScrollbar MacFactory +CreateWindow(): MacWindow +CreateScrollbar(): MacScrollbar AbstractWindow UnixWindow MacWindow AbstractScrollbar UnixScrollbar MacScrollbar Client

Abstract Factory - Applicability When a system should be independent of product creation, composition and representation configured with one of multiple families of products When a family of related product objects are designed to be used together When you want to provide a class library revealing only interfaces and not implementation

Abstract Factory - Consequences Isolates concrete classes Makes exchanging product families easy Promotes consistency among products Supporting new kinds of products is difficult

Thank you for listening, see you next time!