Software Engineering Lecture 7 - Design Patterns

1. Software EngineeringLecture 7- Design Patterns

2. 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

3. About the assignment • Goal • 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

4. Useful terms 1(4) • Signature • Interface • Type • Instance • Encapsulation

5. Useful terms 2(4) • Inheritance • Override • Composition • Dynamic binding • Polymorphism

6. Useful terms 3(4) • Abstract vs concrete • Interface vs class • Inheritance vs composition • Composition and delegation

7. Useful terms 4(4) • Aggregation vs acquaintance • Run-time vs compile-time structures • Toolkit vs framework

8. 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

9. 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

10. 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”

11. Three 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

12. Scenario

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

14. Singleton

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

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

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

18. 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

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

20. 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

21. Factory Method

22. 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

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

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

25. 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

26. Factory Method – example cont. 01. public interface PushPositionDevice extends PositionDevice { 02. public voidaddPositionListener(PositionListener pl); 03. } 04. 05. public class DeviceManager implements PositionListener { 06. synchronized voidloadAllDevices() { 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. // …} // …}

27. Factory method -- usage • Consequences • Makes dynamic architectures possible

28. Abstract Factory

29. 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();

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

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

32. 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

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

34. Thank you for listening, see you next time!