1. Software Engineering Lecture 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 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

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

5. 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…

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

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

8. Scenario

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

10. Singleton

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

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

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

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

15. 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() {
if (uniqueInstance == null)
uniqueInstance = new Singleton();
return uniqueInstance;
14. }

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

17. Factory Method

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

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

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

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

22. 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() {
String[] deviceClasses = getDevices();
08.
for (int i=0; i < deviceClasses.length; i++) {
try {
11. Class c = Class.forName(deviceClasses[i]);
12. // open up the device
13. PushPositionDevice pd = (PushPositionDevice) c.newInstance(); }
} catch (Exception err) { }
// …} // …}

23. Factory method -- usage
Consequences
Makes dynamic architectures possible

24. Abstract Factory

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

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

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

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

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

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