TDDB84. Summary & wrap-up & some tips & some design patterns & some other stuff. tisdag 20 oktober 15

Transcription

1 TDDB84 Summary & wrap-up & some tips & some design patterns & some other stuff

2 Agenda Course goals, expectations Writing papers: FAQ Design Patterns revisited Course summary Life after the course

3 Course goals Identify and explain software design principles and design patterns in existing object-oriented software. Lab 1, 2

4 Course goals Apply software design principles and design patterns when working with existing object-oriented software. Lab 1, 3

5 Course goals Describe the purpose and consequences of design patterns in object-oriented software. Lab 2, 3, final paper

6 Course goals Critically evaluate software design principles and design patterns in relationship to software qualities. Lab 3, final paper

7 Course goals Analyze the relationship between software design principles, design patterns, programming languages and application frameworks. Final paper

8 Expectations Learn about design patterns Learn when to use design patterns Learn about design patterns in real software Learn about the consequences of design patterns

9 Writing Papers, FAQ

10 Writing Papers, tips Be specific precise formal direct unapologetic What is complexity? Design complexity, cyclomatic complexity? This is not a popular science text. Refrain from wording that is ambiguous or less well defined ( forgiving, good, bad, easy ) Do not say something is very hard, use a reference and be precise about what exactly that reference says Do not say you will do something, or intends, be direct and state what you DO, or have DONE. You do not have to state someone made me write this, or Due to time constraints : you will ALWAYS have external constraints on your work, as does everyone else. Write about what you have done, do not make excuses for what you have not done.

11 Writing Papers, tips Use references the style of research papers as a guide the hourglass style your team Back up all claims with references Check your wording & justifications against academic publications, not previous years reports. Everything before the narrow part should lead to the waist, and everything after should relate to the waist. Don t let your paper be overly focused on background material: you need to introduce only that which is necessary for someone else of approximately your own backgrounds (before the course) to understand the core of your paper: your evaluation of a specific design pattern. Please do conduct a second round of reviews

12 Design Patterns revisited

13 Principles + Problem = Pattern

14 Principles = SOLID + Some more tips

15 Some more tips Encapsulate what varies Program to an interface not to an implementation Favor Composition over Inheritance Don t call us, we ll call you

16 Some more tips Depend upon abstractions. Do not depend upon concrete classes. Strive for loosely coupled designs between objects that interact Only talk to your friends

17 Some Design Patterns

18 You choose! Strategy Factory Method Decorator Template Method Composite Abstract Factory (+ Dependency Injection) Singleton (+ example in Ruby) Builder Adapter Bridge Observer Chain of Responsibility Memento Command

19 Strategy

20 Strategy Strategy Context Client

21 Strategy: Consequences + Can choose implementation of a strategy at run time + Eliminate hardcoded conditionals - Clients must be aware of different strategies - Communication required between context and strategies + Avoids excessive subclassing - Potentially many strategy objects created

22 Factory Method

23 Factory method (before)

24 Factory method (before) Pizza pizza = null; if (style.equals("ny")) { if (type.equals("cheese")) { pizza = new NYStyleCheesePizza(); } else if (type.equals("veggie")) { pizza = new NYStyleVeggiePizza(); } else if (type.equals("clam")) { pizza = new NYStyleClamPizza(); } else if (type.equals("pepperoni")) { pizza = new NYStylePepperoniPizza(); } } else if (style.equals("chicago")) { if (type.equals("cheese")) { pizza = new ChicagoStyleCheesePizza(); } else if (type.equals("veggie")) { pizza = new ChicagoStyleVeggiePizza(); } else if (type.equals("clam")) { pizza = new ChicagoStyleClamPizza(); } else if (type.equals("pepperoni")) { pizza = new ChicagoStylePepperoniPizza(); } } else { System.out.println("Error: invalid type of pizza"); return null; }

25 Factory method

26 Factory method + Decouples clients from specific dependency classes + Eliminates hardcoded conditionals + Connects parallel class hierarchies (NY*Pizza, Chicago*Pizza) - Requires keeping factory methods in sync with domain classes

27 Decorator

28 Component Decorator Beverage b = new Coffee(); b = new SweetenedBeverage(new SweetenedBeverage(b)); Decorator return 5+beverage.cost();

29 Decorator + Dynamically adds behavior to specific instances of a class + Customizes an abstract class without knowing the implementations - - Decorator objects are not of the same type as the objects it comprises May result in many small objects

30 Template Method

31 class Beverage { public: void preparerecipe(); void boilwater(); void pourincup(); }; class Coffee{ public: void preparerecipe(); void boilwater(); void brewcoffeegrinds(); void pourincup(); void addsugarandmilk(); }; class Tea{ public: void preparerecipe(); brew void boilwater(); void steepteabag(); addcondiments void pourincup(); void addlemon(); };

32 Template method: Consequences + Can isolate the extensions possible to an algorithm + Isolates clients from algorithm changes

33 Template method

34 Default implementations (hooks) public abstract class CaffeineBeverageWithHook { void preparerecipe() { boilwater(); brew(); pourincup(); if (customerwantscondiments()) { addcondiments(); } } boolean customerwantscondiments() { return true; } public class CoffeeWithHook extends CaffeineBeverageWithHook { [... ] public boolean customerwantscondiments() { return getuserinput().tolowercase().startswith("y"); } }

35 Duck[] ducks = { new Duck("Daffy", 8), new Duck("Dewey", 2), new Duck("Howard", 7), new Duck("Louie", 2), new Duck("Donald", 10), new Duck("Huey", 2) }; Template method? Arrays.sort(ducks, new public int compare(duck arg0, Duck arg1) { return new Integer(arg1.weight).compareTo(arg0.weight); } No }); public class Duck implements Comparable<Duck> { String name; int weight; public Duck(String name, int weight) { this.name = name; this.weight = weight; } public String tostring() { return MessageFormat.format("{0} weighs {1}", name, weight); } } public int compareto(duck object) { return new Integer(this.weight).compareTo(object.weight); } Yes

36 // Java 8: With inline lambda Arrays.sort(ducks, (arg0, arg1) -> new Integer(arg1.weight).compareTo(arg0.weight));

37 Composite

38 Waiter Diner menu print() printmenu() Pizza menu Breakfast menu print() Clam Pizza Cheese Pizza Coffee menu Ham & eggs Spam & eggs Eggs & spam Spam, spam & eggs print() Dark roast Coffee Tea Espresso print()

39

40 Client Component Composite Leaf

41 Composite: consequences - + Allow us to treat composite objects and individual objects uniformly Creates composite classes that violate the principle of a single responsibility + Allows arbitrarily complex trees - The composite cannot rely on components to implement all methods

42 Abstract factory

43 Ingredients Pizza Store Clients Fresh Clam Mozzarella Cheese NY Thin Crust Dough I Want a Cheese Pizza Frozen Clam Parmesan Cheese Chicago Thick Crust Dough

44

45

46

47

48

49 Concrete Factory Abstract Factory Abstract Products

50 Clients

51 Abstract factory: consequences + Isolates clients from concrete dependencies + Makes interchanging families of products easier

52 Strategy When related classes only differ in behavior You need different variants of an algorithm An algorithm uses data the clients don t need to know A class uses conditionals for selecting behavior Behavioral Abstract Factory A system should be independent of how its products are created A system should be configured with one of multiple families of products You want to provide a class library of products, and only expose their interfaces Creational

53 Design principles Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you

54 Dependency Injection

55 ICheesePizza -cheese <<ICheese> > StandardCheesePizza MozzarellaCheese ParmesanCheese IClamPizza -cheese -clam <<IClam>> FancyClamPizza FreshClam FrozenClam NYStyle ChicagoStyle Distinguished by namespaces in C#

56 DI: How? 1. Declare dependencies as constructor arguments of interface types 2. Register classes (components) in an Inversion-of-Control Container 3. Resolve the top-level object from an interface through the Container

57 1. Dependencies namespace DITest {! public class FancyClamPizza: IClamPizza! {!! private IClam clam;!! private ICheese cheese;!! public FancyClamPizza (IClam clam, ICheese cheese)!! {!!! this.clam = clam;!!! this.cheese = cheese;!! }!! public String ClamType() {!!! return String.Format("fancy {0}",clam);!! }!! public String Describe() {!!! return String.Format("fancy clam pizza with {0} and {1}",ClamType(), cheese);!! }! } }

58 2. Registration namespace DITest {! public class IoCInstaller: IWindsorInstaller! {!! public void Install(IWindsorContainer container, IConfigurationStore store)!! {!!! container.register(classes!!!.fromthisassembly()!!!.innamespace("ditest.nystyle")!!!.withserviceallinterfaces());!!! container.register (Classes!!!.FromThisAssembly()!!!.AllowMultipleMatches()!!!.InSameNamespaceAs<IoCInstaller>()!!!.WithServiceAllInterfaces());!! }! } } Castle Windsor,

59 3. Resolution!!! var container = new WindsorContainer();!!! // adds and configures all components using WindsorInstallers from executing assembly!!! container.install(fromassembly.this());!!! // instantiate and configure root component and all its dependencies and their dependencies and...!!! var p = container.resolve<icheesepizza>();!!! Console.WriteLine (p.describe ());

60 Singleton

61 public class Singleton { private static Singleton instance = new Singleton(); private String name; public String getname() { return name; } public static void someothermethod(){ System.out.println("Hi there!"); } What about 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

62 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 ns Static method invocation took ns

63 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 ns Singleton name: Anders Singleton lookup took ns

64 What about threads?

65 private Singleton() { try { // Very expensive job indeed Thread.sleep(100); } catch (InterruptedException e) { e.printstacktrace(); } name = Math.random() > 0.5? "Jonas" : "Anders"; } private static final class SingletonLookup implements Runnable public void run() { System.out.println(MessageFormat.format("Singleton name: {0}", Singleton.getInstance().getName())); } } public static void main(string[] args) { Thread t1 = new Thread(new SingletonLookup()); Oops! Thread t2 = new Thread(new SingletonLookup()); t0 = System.nanoTime(); t1.start(); t2.start(); try { t1.join(); Singleton name: Anders t2.join(); Singleton name: Jonas } catch (InterruptedException e) { Singleton name after our threads have run: Anders // TODO Auto-generated catch block e.printstacktrace(); } System.out.println("Singleton name after our threads have run: "+Singleton.getInstance().getName()); }

66 public static synchronized Singleton getinstance() { if (instance == null) { instance = new Singleton(); } return instance; } Singleton name: Anders Singleton name: Anders Singleton lookup took ns Singleton lookup took ns Singleton name after our threads have run: Anders Woohoo!

67 Singleton as Enum public enum EnumSingleton { } INSTANCE; private String name; private int age; public String getname() { return name; } public void setname(string name) { this.name = name; } public int getage() { return age; } public void setage(int age) { this.age = age; }

68 Singletons in Ruby Object MetaClass A class A; end Class Singleton Class for foo class << foo; end Singleton Class for A class << A; end foo foo = A.new A class A; end

69 class A end a = A.new class << A def new raise "Illegal!" end end irb(main):014:0> a #<A:0x007f8d6b92bcb0> irb(main):016:0> A.new RuntimeError: Illegal! from (irb):10:in `new' from (irb):16 from /Users/olale/.rvm/rubies/ruby p247/bin/irb:13:in `<main>' Now we have one object, but we cannot produce another of the same class

70 Singleton: consequences - + Ensures single objects per class Violates several design principles!

71 Singleton considered dangerous Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change Strive for loosely-coupled design

72 Builder

73

74 Client Director Builder build() builda() buildb() buildc() getproduct()

75

76 Client Director Builder

77 Abstract Factory Client receives a Factory Client requests a product from Factory Client receives an abstract product Builder Client initializes Director with Builder Client asks Director to build Client requests product from Builder Client receives a builder-specific product

78 Builder: consequences + Can control the way objects are created + Can produce different products using the same Director - - Not necessarily a common interface for products Clients must know how to initialize builders and retrieve products

79 Adapter

80 Class Adapter Object Adapter

81 Multiple back-end objects Client Target do() Adapter -adaptee1 -adaptee2 do() Adaptee1 +perform() Adaptee2 +perform()

82 Multiple back-end methods Client Target do() Adapter -adaptee do() Adaptee1 +foo() +bar() adaptee.foo() adaptee.bar()

83 public interface Duck { public void quack(); public void fly(); } public interface Turkey { public void gobble(); public void fly(); } public class TurkeyAdapter implements Duck { Turkey turkey; } public TurkeyAdapter(Turkey turkey) { this.turkey = turkey; } public void quack() { turkey.gobble(); } public void fly() { for(int i=0; i < 5; i++) { turkey.fly(); } } public class DuckAdapter implements Turkey { Duck duck; Random rand; } public DuckAdapter(Duck duck) { this.duck = duck; rand = new Random(); } public void gobble() { duck.quack(); } public void fly() { if (rand.nextint(5) == 0) { duck.fly(); } }

84 Adapter: consequences + Isolates interface changes to the adapter class - Class adapters require target interfaces or multiple inheritance in the language

85 Bridge

86 Abstraction == That which we (should) care about

87 TV Samsung LG Logitech Harmony On() Off() On() Off() Remote One For All On() Off() On() Off()

88 Message type Password recovery Signup Send() Send() Transmission type SMS Send() Send()

89 Bridge Strategy Intent Collaborations Decouple two class hierarchies (abstraction/ implementation) The Bridge forwards requests to the Implementor Allow for exchangeable algorithms The Context and Strategy collaborate, passing data between them

90 Bridge Adapter Intent Decouple two class hierarchies (abstraction/ implementation) Convert an existing class to fit a new interface Applicability In a new system In an existing system

91 Design principles Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change

92 Bridge: consequences + Lets two class hierarchies with common superclasses vary independently - If some implementation classes do not support an abstract concept, the abstraction breaks

93 Observer

94

95 Weather Station Humidity Display Average Temp Display subscribe() subscribe() publish() publish() unsubscribe() publish()

96

97 Subject Concrete Observer

98 Mediator vs Observer

99 Design principles Encapsulate what varies Program to an interface, not to an implementation Favor composition over inheritance Classes should be open for extension but closed for modification Don t call us, we ll call you Depend on abstractions, do not depend on concrete classes Classes should only have one reason to change Strive for loosely-coupled design

100 Chain of Responsibility

101 SPAM Filter isspam(message) accept Size Filter istoolarge(message) accept Sorting Filter sort(message) process reject reject Message arrived Message rejected

102

103 Examples Logging Input management in GUI:s

104 CoR: consequences + provides the Observer with more control over invocation of targets - A handler does not know if it will receive a message, depending on the behavior of other handlers in the chain

105 Memento

106

107 Iterative Optimizer iteration current target value current solution Optimize() Abort() GetState() SetState() SolverMemento iteration current target value current solution Client - memento - optimizer Optimize() Abort() ResetOptimizer(SolverMemento)

108

109 Mementos in GUI:s - Undo/Redo User Name Age gi Ginnie gi jo User Name Ginnie Johnny Age Undo Redo Cut Copy Paste Paste special... 4 gi User Name Ginnie Age 24 Delete Select All

110 Memento: consequences - + Can externalize object state for later restoration within the lifetime of the object + Encapsulates access to the objects inner state Depending on implementation, access to private fields requires memento classes as inner/friend classes to each domain class

111 Command

112 Command Client Waiter Order Chef Order Place Order Cook

113 Remote control Joe s Ultimate Remote Control Fan High() Low() Off() GetSpeed() On Off On Off On Off On Off On Off On Off On Off Undo On() Off() Dim() Lamp TV TurnOn() TurnOff() SetChannel() TDDB84 Design Patterns

114 Client Invoker -command perform() Command +execute() Receiver +perform() Concrete Command -receiver

115 Client Invoker Concrete Commands Receiver Command

116 Command: consequences + Allows extensions of commands + Decouples the execution from the specification of the command - - Bad design if not needed! May be confusing if it removes the receiver from responsibilities

117 Course summary Practical work: Intro seminar + three labs Reflection and analysis: Reading a research paper, and studying design patterns in a real context

118 Life after the course Writing your papers :) Masters theses: 12:15! Research project in Software Engineering Exam? No.

119 Thanks for your participation, and good luck with your papers!