TDDB84: Lecture 5 Singleton, Builder, Proxy, Mediator fredag 27 september 13
Creational Singleton Abstract Factory Builder Structural Bridge Composite Proxy Adapter Template method Behavioral Iterator Chain of responsibility Mediator Observer LE3 LE4 LE5 LE6 Observer Creational patterns Structural patterns LA1 LA2 LA3 fredag 27 september 13
Creational Singleton Abstract Factory Builder Structural Bridge Composite Proxy Adapter Dynamic proxies in C# & Java Template method Behavioral Iterator Chain of responsibility Mediator Observer Classes ARE objects, and each object can have a class (in Ruby) LE3 LE4 LE5 LE6 Observer Creational patterns Structural patterns LA1 LA2 LA3 fredag 27 september 13
Muddy Cards • Compare patterns • Fewer examples • Present more patterns • More UML • Lab session staffing/time sharing fredag 27 september 13
The assistant role Let me go! fredag 27 september 13
The assistant role Let me go! fredag 27 september 13
On UML fredag 27 september 13
What is this? y.g() X Y y g() f() X1 Y1 Y2 fredag 27 september 13
Bridge? fredag 27 september 13
Builder? fredag 27 september 13
Strategy? strategy.g() Context Strategy strategy g() f() Context1 ConcreteStrategy1 ConcreteStrategy2 fredag 27 september 13
What UML? Arrays.sort(ducks, (arg0, arg1) -> new Integer(arg1.weight).compareTo(arg0.weight)) fredag 27 september 13
1. What are the relationships between the Strategy and Flyweight patterns? a) They both concern decoupling objects from their dependencies b) Using a Flyweight pattern may also require the Strategy pattern c) Using the Strategy pattern may also result in using the Flyweight pattern d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern e) You often implement the Flyweight pattern by using the Strategy pattern for object creation f) The Flyweight pattern is a simplified form of the Strategy pattern fredag 27 september 13
1. What are the relationships between the Strategy and Flyweight patterns? a) They both concern decoupling objects from their dependencies True. As in the strategy pattern behavior or independent and in the flyweight pattern we implement a kind of factory which decouple object from their dependencies. b) Using a Flyweight pattern may also require the Strategy pattern False. c) Using the Strategy pattern may also result in using the Flyweight pattern True. As behavior (strategy objects) can be implemented as flyweight to enable to share behavior objects, and avoid creating several time the same behavior object. d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern False. I think that using template parameters doesn't prevent from creating unnecessary new objects. e) You often implement the Flyweight pattern by using the Strategy pattern for object creation False. As strategy pattern is not a creational pattern and enable to use different algorithm and not to create different objects. f) The Flyweight pattern is a simplified form of the Strategy pattern False. UML seems similar (GoF p198, 316) but they don't do the same thing at all, strategy enable to use different algorithm and change them runtime whereas the goal of flyweight pattern is to create new object, if they weren't created before,or to share object if the same object was created before. fredag 27 september 13 Correct answers marked
1. What are the relationships between the Strategy and Flyweight patterns? a) They both concern decoupling objects from their dependencies True. As in the strategy pattern behavior or independent and in the flyweight pattern we implement a kind of factory which decouple object from their dependencies. b) Using a Flyweight pattern may also require the Strategy pattern False. c) Using the Strategy pattern may also result in using the Flyweight pattern True. As behavior (strategy objects) can be implemented as flyweight to enable to share behavior objects, and avoid creating several time the same behavior object. d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern False. I think that using template parameters doesn't prevent from creating unnecessary new objects. e) You often implement the Flyweight pattern by using the Strategy pattern for object creation False. As strategy pattern is not a creational pattern and enable to use different algorithm and not to create different objects. f) The Flyweight pattern is a simplified form of the Strategy pattern False. UML seems similar (GoF p198, 316) but they don't do the same thing at all, strategy enable to use different algorithm and change them runtime whereas the goal of flyweight pattern is to create new object, if they weren't created before,or to share object if the same object was created before. fredag 27 september 13 Correct answers marked
c) Using the Strategy pattern may also result in using the Flyweight pattern Flyweights are light-weight objects with externalized state, useful if supplying multiple strategies to a problem-solving context d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern Using a template parameter, See C# demo public class TaxCalculation<T> � � where T: TaxStrategy, new() � { � � private static T taxStrategy = Activator.CreateInstance<T>(); � � public TaxCalculation () � � { � � } � � public double GetTax(Person p) { � � � return taxStrategy.calculateTax(p.Salary); � � } � } fredag 27 september 13
c) Using the Strategy pattern may also result in using the Flyweight pattern Flyweights are light-weight objects with externalized state, useful if supplying multiple strategies to a problem-solving context d) The Strategy pattern, if implemented with the use of type template parameters, does not necessitate the Flyweight pattern Using a template parameter, See C# demo public class TaxCalculation<T> � � where T: TaxStrategy, new() � { � � private static T taxStrategy = Activator.CreateInstance<T>(); � � public TaxCalculation () � � { � � } � � public double GetTax(Person p) { � � � return taxStrategy.calculateTax(p.Salary); � � } � } fredag 27 september 13
Singleton fredag 27 september 13
public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getName() { return name; } private Singleton() { [ ... ] } } fredag 27 september 13
public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getName() { return name; } private Singleton() { [ ... ] } } private Singleton() { try { // Very expensive job indeed Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } name = Math.random() > 0.5 ? "Jonas" : "Anders"; } fredag 27 september 13
public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getName() { return name; } private Singleton() { [ ... ] } } private Singleton() { try { // Very expensive job indeed Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } name = Math.random() > 0.5 ? "Jonas" : "Anders"; } Our app takes forever to load fredag 27 september 13
public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getName() { return name; } What about public static void someOtherMethod(){ System.out.println("Hi there!"); static methods? } private Singleton() { [ ... ] } } private Singleton() { try { // Very expensive job indeed Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } name = Math.random() > 0.5 ? "Jonas" : "Anders"; } Our app takes forever to load fredag 27 september 13
Thread t1 = new Thread(new StaticMethodInvocation()); Thread t2 = new Thread(new SingletonLookup()); t0 = System.nanoTime(); t1.start(); t2.start(); try { t1.join(); t2.join(); } catch (InterruptedException e) { // TODO Auto-generated catch block e.printStackTrace(); } someOtherMethod invoked Singleton name: Anders Singleton lookup took 1 003 348 000 ns Static method invocation took 1 002 463 000 ns fredag 27 september 13
How about now? private static Singleton instance; public static Singleton getInstance() { if (instance == null) { instance = new Singleton(); } return instance; } someOtherMethod invoked Static method invocation took 899 000 ns Singleton name: Anders Singleton lookup took 1 002 277 000 ns fredag 27 september 13
What about threads? fredag 27 september 13
private Singleton() { try { // Very expensive job indeed Thread.sleep(100); } catch (InterruptedException e) { e.printStackTrace(); } name = Math.random() > 0.5 ? "Jonas" : "Anders"; } fredag 27 september 13
Recommend
More recommend
