Design Patterns Lecture 1 Josef Hallberg josef hallbergltu

Design Patterns Lecture 1 Josef Hallberg josef. hallberg@ltu. se 1

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 2

About the assignment • Goal – Learn about different patterns – Learn how to apply patterns • Task – Read about the patterns – Discuss and select 3 patterns – Apply the 3 patterns to your design – Motivate your choices 3

Reading the book • • • Get an overview Skim Skip Understand the purpose Leave details for later 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 objectoriented 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

Why use design patterns? cont. • 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

Let’s take a break! 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 Underlined means static + Instance() : Singleton + Singleton. Operation() + Get. Singleton. Data() : singleton. Data Return unique. Instance + unique. Instance() : Singleton singleton. Data 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 unique. Instance; 04. 05. // private constructor 06. private Singleton() { 07. } 08. 09. // instantiation method 10. public static Singleton Instance() { 11. if (unique. Instance == null) 12. unique. Instance = new Singleton(); 13. return unique. Instance; 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 + Factory. Method() : Product + An. Operation() Concrete. Product Concrete. Creator + Factory. Method() : Concrete. Product 25

Factory Method - example • Alipes example – Several positining-tecniques – Available positining services vary between devices • Factory Method – Create a common interface (Push. Position. Device) – Implement support for a positioning-technique, implement the Push. Position. Device interface – Let the factory instantiate the necessary positioningdevices 26

Factory Method – example cont. 01. public interface Push. Position. Device extends Position. Device { 02. public void add. Position. Listener(Position. Listener pl); 03. } 04. 05. public class Device. Manager implements Position. Listener { 06. synchronized void load. All. Devices() { 07. String[] device. Classes = get. Devices(); 08. 09. for (int i=0; i < device. Classes. length; i++) { 10. try { 11. Class c = Class. for. Name(device. Classes[i]); 12. // open up the device 13. Push. Position. Device pd = (Push. Position. Device) c. new. Instance(); 14. } 15. } catch (Exception err) { 16. } 17. //. . . 18. } 19. //. . . 27 20. }

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: – Unix. Window w = new Unix. Window(); 30

Abstract Factory - Solution Client Abstract Factory Abstract. A +Create. A(): Abstract. A +Create. B(): Abstract. B A 1 A 2 Abstract. B Concrete. Factory 1 +Create. A(): A +Create. B(): B B 1 B 2 Concrete. Factory 2 +Create. A(): A +Create. B(): B 31

Abstract Factory – Solution Client Abstract Factory Abstract. Window +Create. Window(): Abstract. Window +Create. Scrollbar(): Abstract. Scrollbar Unix. Window Mac. Window Abstract. Scrollbar Unix. Factory +Create. Window(): Unix. Window +Create. Scrollbar(): Unix. Scrollbar Mac. Factory +Create. Window(): Mac. Window +Create. Scrollbar(): Mac. Scrollbar 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! 35