20 Years of. Improve the Design of your Code. Dr Dimitris Dranidis JAVA Meetup Group, Thessaloniki May 2015

Transcription

1 20 Years of Design Patterns Improve the Design of your Code Dr Dimitris Dranidis JAVA Meetup Group, Thessaloniki May 2015

2 Dr Dimitris Dranidis Senior Lecturer in Computer Science Department Programme director of the MSc in Software Engineering & Telecommunications MSc in Business, Management, Technology and Innovation Leader of the "Software Engineering & Service-Oriented Technologies" research group, r Research interests: service-oriented computing, Cloud computing model-based testing, formal methods, software engineering education 2

3 Experience in software project management >10 years of management of >50 short (~3 pms) software projects Industrial Group Projects Teams of undergraduate and postgraduate students developing software for the industry Plenty of successes and failures 3

4 Experience in Java/Design Patterns Teaching Design Patterns for 15 years Advanced Software Development Techniques MSc in Software Engineering and Telecommunications Principal Developer of JSXM Model-based testing tool 14 KLOC (JSXM core) Plenty of Design Patterns applied 4

5 Your experience? Familiarity with Java? UML? Design Patterns? 5

6 Outline Quiz problem Bad smells in design Open/Closed principle Design Patterns Examples of Design Patterns Quiz solution Key points 6

7 A PROBLEM TO KEEP YOU BUSY! 7

8 Current Design ( Your current implementation of a class DocumentPrinter is as follows: class DocumentPrinter { public void printdocument(document doc) { if (doc.gettype().equals("pdf")) { PDFPrinter pdfprinter = new PDFPrinter(); pdfprinter.printpdf(doc.getcontent()); else if (doc.gettype().equals("html")) { HTMLPrinter htmlprinter = new HTMLPrinter(); htmlprinter.printhtml(doc.getcontent()); else throw new RuntimeException("Wrong type of document"); 8

9 Constraints Library classes (These classes cannot be modified). Document, PDFPrinter and HTMLPrinter You are expecting other types of documents to be handled in the future and you would not like to change your DocumentPrinter class continuously. Change DocumentPrinter once and for all! Make it open for extensions and closed to modifications! 9

10 What we wish to avoid: class DocumentPrinter { public void printdocument(document doc) { if (doc.gettype().equals("pdf")) { PDFPrinter pdfprinter = new PDFPrinter(); pdfprinter.printpdf(doc.getcontent()); else if (doc.gettype().equals("html")) { HTMLPrinter htmlprinter = new HTMLPrinter(); htmlprinter.printhtml(doc.getcontent()); else if (doc.gettype().equals( XML")) { XMLPrinter xmlprinter = new XMLPrinter(); xmlprinter.printxml(doc.getcontent()); else throw new RuntimeException("Wrong type of document"); 10

11 DESIGN SMELLS 11

12 Design smells Rigidity: Hard to change A change forces many other unforeseen changes Changing it was a lot more complicated than I thought Fragility: Easy to break A change forces the application to break in often unforeseen ways Fragile modules: The more you fix them the worst they get Immobility: Hard to reuse Useful parts are hard to separate Viscosity: Hard to do the right thing Many ways to deal with change; hacks are easier than design-preserving ways Caused by the software or the environment 12

13 Design smells Needless complexity: Overdesign Not useful (even unused) design elements Dealing with anticipated requirements Needless repetition: Cut & Paste abuse Redundant code Bugs require repetitive and different fixes Opacity: Difficult to understand Easy when you write it, difficult when you read it 13

14 OPEN-CLOSED PRINCIPLE 14

15 OCP: Open-Closed Principle A module should be Open for extension Closed for modification Client Server How can we extend the client so that it works with other servers (OPEN) without having to modify the client (CLOSED)? 15

16 OCP: Abstraction is the key! Client «interface» ClientInterface Server Bertrand Meyer 97 16

17 DESIGN PATTERNS 17

18 What are Design patterns? Well-known best design practices Named solutions to design problems by experienced developers Let s apply a Factory and a Strategy! Vocabulary of principles to design software 18

19 A Pattern Language: Towns, Buildings, Construction (1977) Book on architecture, urban design, and community livability. Patterns describe a problem and then offer a solution. Still one of the best-selling books on architecture 19

20 Gang of Four (GoF) Design Patterns (1994) 23 patterns categorized in Creational Structural Behavioral 20

21 Quotes from the Book Program to an interface, not an implementation Favor object composition over class inheritance Inheritance breaks encapsulation Implement abstract classes, do not inherit concrete classes! 21

22 22 PLoP conferences (1994-today) Pattern Languages of Programs Annual conferences *PLoP 22

23 Patterns in core Java All patterns have been implemented in Java s core libraries: /examples-of-gof-design-patternsin-javas-core-libraries or google: Examples of GoF Design Patterns in Java 23

24 DESIGN PATTERNS EXAMPLES 24

25 SHAPES EXAMPLE 25

26 Shapes example public class Rectangle { private double width; private double height; public Rectangle ( double w, double h ) { width = w ; height = h ; public double getarea() { return width * height ; 26

27 Shapes example public class AreaPrinter { private Rectangle shape; public AreaPrinter (Rectangle s ) { shape = s ; public void printarea () { System.out.println( "Shape area : " + shape.getarea() ) ; public class Main { public static void main( String arg[] ) { Rectangle rectangle = new Rectangle(2.0, 5.0); AreaPrinter ap = new AreaPrinter( rectangle ) ; ap.printarea () ; 27

28 Desired extensions We want our application to work with other types of shapes: Squares, Triangles, Circles, Polygons, etc. public class Square { private double width; public Square ( double w ) { width = w ; public double getarea() { return width * width ; Do we need another AreaPrinter for Square? Can we make AreaPrinter work for both Rectangle and Square? 28

29 Abstraction is the key! public interface Shape { public double getarea(); public class AreaPrinter { private Shape shape; public AreaPrinter ( Shape s ) { shape = s ; public void printarea () { System.out.println( "Shape area : " + shape.getarea() ) ; AreaPrinter is now open to extensions, closed to modifications! 29

30 Concrete classes implement the desired interface public class Rectangle implements Shape { private double width; private double height; public Rectangle ( double w, double h ) { width = w ; height = h ; public double getarea() { return width * height ; public class Square implements Shape { private double width; public Square ( double w ) { width = w ; public double getarea() { return width * width ; 30

31 Polygons? Polygons area is hard to calculate! We would not like to write the code ourselves. Luckily we find a class Polygon which offers the calculation of its objects area. Source code not available OR We don t wish to change the implementation of Polygon public class Polygon {... public Polygon ( List points ) {... public double computearea () { How can we integrate polygons into our Shapes application? 31

32 Adapter Design Pattern public class PolygonAdapter implements Shape { private Polygon polygon; // composition public PolygonAdapter (Polygon c ) { polygon = c ; public double getarea () { return polygon.computearea() ; // indirection 32

33 Main client public class Main { public static void main( String arg[] ) { Rectangle rectangle = new Rectangle(2.0, 5.0); AreaPrinter ap = new AreaPrinter( rectangle ) ; ap.printarea () ; Square square = new Square (3.0); AreaPrinter sp = new AreaPrinter( square ) ; sp.printarea () ; Polygon polygon = new Polygon (...); AreaPrinter pp = new AreaPrinter ( new PolygonAdapter(polygon)); pp.printarea () ; 33

34 Adapter (GoF, Structural Pattern) Intent convert the interface of an existing class into another interface used by clients Motivation: want to use an existing class but... interface of class is not compatible to the one you use and modification of class is out of question because source code of class is not available or it is a general-purpose class (you do not want to modify) resolve incompatible interfaces provide a stable interface to similar classes with different interfaces 34

35 Problem Client <<interface>> Target +request() Adaptee +specificrequest() incompatible interfaces 35

36 Adapter Solution Client <<interface>> Target +request() Adaptee +specificrequest() Adapter +request() specificrequest() 36

37 Adapter Solution Target :Client :Adapter :Adaptee 1: request() 2: specificrequest() 37

38 EMPLOYEE EXAMPLE 38

39 Current design public class Employee { private double salary ; public Employee (double s) { salary = s ; public double getpayamount () { return salary ; Assume that some privileged employees receive double salary Assume that employees can be promoted How can we extend Employee to protect it from changes? 39

40 2 possible solutions Sub-typing (Inheritance) Include a type attribute 40

41 Sub-typing solution (??) public class Manager extends Employee { public double getpayamount () { return 2 * salary ; 41

42 Sub-typing solution does not work! Objects cannot dynamically change their type An Employee object cannot be converted to a Manager object More points of variation create class explosion! Different types of employees could have different promotion eligibility criteria Leading to a huge inheritance hierarchy tree. 42

43 Type attribute solution (??) (Too smelly, violates OCP) public class Employee { private int type ; private double salary ; public static final int ENGINEER = 1; public static final int MANAGER = 2; public Employee (double s, int t) { salary = s ; type = t ; public double getpayamount () { if (type == Employee.ENGINEER) return salary; if (type == Employee.MANAGER) return salary ; return salary * 2; 43

44 Strategy Pattern solution public interface PaymentStrategy { public double getpayamount (Employee context); public class EngineerPaymentStrategy implements PaymentStrategy { public double getpayamount (Employee empl) { return empl.getsalary() ; public class ManagerPaymentStrategy implements PaymentStrategy { public double getpayamount (Employee empl) { return empl.getsalary() * 2 ; 44

45 Strategy Pattern solution public class Employee { private PaymentStrategy paymentstrategy ; // composition private double salary ; public Employee (double s, PaymentStrategy strategy) { salary = s ; paymentstrategy = strategy ; public double getsalary () {return salary ; public double getpayamount () { return paymentstrategy.getpayamount(this) ; // indirection 45

46 Strategy (GoF: Behavioral) Intent define a family of related algorithms, encapsulate each one, and make them interchangeable by providing a common interface algorithm may vary by object and also may vary over time Motivation: Many different algorithms exist for fulfilling a responsibility You need different variants of an algorithm An algorithm uses data that clients shouldn't know about A class defines many behaviors, and these appear as multiple switch statements in the classes operations Many related classes differ only in their behavior 46

47 Strategy (GoF) Motivation (cont): Separate the algorithms from the object which is using them because an object may decide to change the algorithm it uses an object will get complex if you include all the code of the algorithms an object will have to use conditionals to decide which algorithm it will use each algorithm uses its own algorithm-specific data it is difficult to add new algorithms if they are hard coded in the object. 47

48 Strategy Solution Context +contextinterface() <<interface>> Strategy +algorithminterface( context : Context ) strategy.algorithminterface(this) ConcreteStrategyA +algorithminterface( context ) ConcreteStrategyB +algorithminterface( context ) 48

49 KEY POINTS 49

50 When should you use patterns You have to add some new functionality and you find out that: You need to copy and paste code You need to hack the solution Current design does not allow easy fit of the new functionality 50

51 Protect your code from changes Identify the variation points Isolate the variation points, separate them from what is stable. Encapsulate variations in a method/class method encapsulation Template method, Factory method class encapsulation Strategy, Abstract Factory 51

52 When NOT to use Design Patterns Patterns introduce complexity Simple problems require simple solutions Over-conformance to good design principles leads to Needless Complexity Apply Design Patterns only when it is necessary! Remember: Not everything is a nail! 52

53 SOLUTION TO PROBLEM 53

54 Current Design ( class DocumentPrinter { public void printdocument(document doc) { if (doc.gettype().equals("pdf")) { PDFPrinter pdfprinter = new PDFPrinter(); pdfprinter.printpdf(doc.getcontent()); else if (doc.gettype().equals("html")) { HTMLPrinter htmlprinter = new HTMLPrinter(); htmlprinter.printhtml(doc.getcontent()); else throw new RuntimeException("Wrong type of document"); 54

55 Analysis of the problem Variation points: Objects created: PDFPrinter pdfprinter = new PDFPrinter(); HTMLPrinter htmlprinter = new HTMLPrinter(); Interface of objects: pdfprinter.printpdf(doc.getcontent()); htmlprinter.printhtml(doc.getcontent()); 55

56 Adapter (Providing a stable interface) public interface Printer { public void print (String content); public class PDFPrinterAdapter implements Printer { public void print (String content) { PDFPrinter pdfprinter = new PDFPrinter(); pdfprinter.printpdf(content); similar for HTMLPrinterAdapter 56

57 Factory (GoF Creational) (Provides a stable interface for object creation) public class PrinterFactory { Printer makeprinter (String doctype) { if (doctype.equals("pdf")) { return new PDFPrinterAdapter(); else if (doctype.equals("html")) { return new HTMLPrinterAdapter() else throw new RuntimeException(" "); 57

58 Singleton (GoF Creational) public class PrinterFactory { static PrinterFactory printerfactory = new PrinterFactory(); protected PrinterFactory() { static PrinterFactory getinstance() { return printerfactory; Printer makeprinter(string doctype) {. 58

59 Final DocumentPrinter (Open for extensions, closed for modifications) class DocumentPrinter { public void printdocument(document doc) { PrinterFactory printerfactory = PrinterFactory.getInstance(); Printer printer = printerfactory.makeprinter (doc.gettype()); printer.print (doc.getcontent()); 59

60 or as one-liner! class DocumentPrinter { public void printdocument(document doc) { PrinterFactory.getInstance().makePrinter (doc.gettype()). print (doc.getcontent()); 60

61 How to learn Design Patterns Pick a pattern and then find, and read as many examples as possible Focus on the problems the patterns solves, NOT the solution! Invent your own examples/problems Apply the Design Pattern and enjoy! 61

62 How to apply Design Patterns Follow a problem-directed approach: Identification of the pattern needed: understand the problem find a pattern that addresses the problem (or a similar problem) Study the Pattern solution UML diagrams code example (C++, Java, ) Apply the solution to the problem embed pattern name in class/method names 62

63 Recommended Readings Design Patterns, GoF Refactoring, Martin Fowler Agile Software Development, Robert Martin Avoid all the Design Patterns in XXX++## books! 63

64 Thank you! Questions? 64