TEAM 4: DESIGN PATTERNS

1. TEAM 4: DESIGN PATTERNS BY Piyush Vijayvargiya Young Jin Kim Bimesh Giri Arkadiy Gorelik SPRING 2003, COMP 680

2. Introduction

3. What is a PATTERN? • A description of a solution to a recurring problem within a context, proven by experience to lead to a superior result when properly applied. • A design pattern is a description of communicating objects and classes that are customized to solve a general design problem in a particular context

4. Why a Design Pattern • Reusability: For an efficient and actual SE discipline. • Helping new designers to have a more flexible and reusable design. • Improving the documentation and maintenance of existing system by furnishing an explicit specification of class and object interactions and their intent.

5. History of Design Pattern • 1979:Christopher Alexander,architect, “The Timeless Way of Building”,Oxford Press. • 1987:OOPSLA (Object Oriented Programming System),Orlando, presentation of design pattern to the community OO by Ward Cunningham and Kent Beck. • 1995:Group of Four alias E.Gamma, R.Helm,R.Johnson and J.Vlissides : “Design Pattern:Elements of Reusable OO software”.

6. Pattern Characteristics • Each pattern has a name. • Patterns follow a loosely standardized document format, generally employing a conversational tone. • They may also include diagrams, pictures or source code to help the reader understand the pattern. • Additionally, each pattern provides suggestions of other possible patterns to consider instead of, or in conjunction with that particular pattern to help solve larger problems. • Thus patterns are literary form of Problem Solving.

7. Essential Qualities of a True Pattern. • Quality Without a Name (QWaN): Fundamentally, QWaN means that, when applied correctly to solve an applicable problem, the resulting solution provides a structure that can evolve over time to meet unanticipated future needs.

8. Essential Qualities Cont. • Rule of Three : • In order for a solution to really be a 'pattern', there must already exist known uses of the solution, with results that can be observed. • This rule states that, for any solution to be a true pattern, there must be at least three known instances of that solution.

9. Essential Qualities Cont. • Pattern Format: • Patterns are documented following a loosely standardized format. • FORMAT: The structure of any solution presented as a pattern may be informal or formal. Minimally, each pattern must specify a name, the purpose of the pattern, a description of the solution and the forces it resolves. Additional sections may be included as well.

10. Pattern Formats • A pattern may be very brief - consisting of only a few paragraphs of conversational text - or it may be documented in many pages of a book or published paper. • A pattern may be very loosely or strictly structured. For software design patterns, a more strict structure is usually preferred, with each pattern divided into a number of topic sections.

11. Common pattern sections • Name • Problem or Intent • Context or Applicability • Solution • Forces or Consequences • Related Patterns • Known Uses

12. Name of Design Pattern • Have to be coherent and evocative. • Describe a design problems and its solutions in one or two sentences. • Used to talk about design pattern with the colleagues. • Used in the documentation.

13. Problem or Intent • Describes when to apply the patterns. • Explains the problem and its context. • Sometimes include a list of conditions that must be met before it makes sense to apply the pattern. • Have to occur over and over again in our environment.

14. Context or Applicability • This is the section which tells that when the particular pattern can be applied and what is the problem in a particular context that can be solved using the particular pattern.

15. Solution • Describes the elements that make up the design, their relationships, responsibilities and collaborations. • Does not describe a concrete design or implementation. • Has to be well proven in some projects.

16. Forces or Consequences • Results and trade-offs of applying the pattern. • Helpful for describe design decisions, for evaluating design alternatives. • Benefits of applying a pattern. • Impacts on a system’s flexibility, extensibility or portability

17. Related Patterns • This section mentions the names of the other known patterns which are related to this pattern and are used to get to the solution of the problem encountered in the particular context . • Or it can be give the names of the pattern which are almost the same and can be used as substitute patterns.

18. Known Uses • As we have already seen that in order for a pattern to be a true pattern there should be at least three independent instances of the solution provided by the pattern. • So this section list some of the known uses of the pattern.

19. Classification of Design Patterns • The design Patterns may be Classifies as • Creational Design Patterns. • Structural Design Patterns. • Behavioral Design Patterns.

20. Classification of design patterns ( a view)

21. Creational Design Patterns

22. Objective • Concept of creational design pattern. • Understanding of 5 different creational design patterns with code examples. • The right usage of creational design patterns. • Giving an idea of how to create object using Design pattern to apply your own application.

23. What is creational Design pattern? • About how an object can be created. CreationalPatterns CreatingObject Client Application request Return object Encapsulated

24. What is creational Design pattern? (cont) • Design patterns that abstracts the object instantiation process. • help system be independent of how its objects are created, composed, and represented • Client application just use object without know how it’s created.

25. What is creational Design pattern? (cont) • examples of object creation • JFrame myFrame=new JFrame(“Sky”);//new operator create object • Border blackline= BorderFactory.createLineBorder(Color.black);//calling method to get specific object from object Factory • JPanel drawingPanel= new JPanel();Graphics g= drwaingPanel.getGraphics();//Graphic object is created depending on panel object.

26. Kinds of Creational Design pattern • The Factory Method. • The Abstract Factory Method • The Builder Pattern • The Prototype Pattern • The Singleton Pattern

27. Kinds of Creational Design pattern(brief introduction) • The Factory Method:defines an interface for creating an object, but let subclasses decide which class to instantiate. • The Abstract Factory Method:provides an interface for creating families of related or dependent objects without specifying their concrete classes.

28. Kinds of Creational Design pattern(brief introduction)(cont) • The Builder Patternseparates the construction of a complex object from its representation so that the same construction process can create different representations • The Prototype Patternspecifies the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

29. Kinds of Creational Design pattern(brief introduction)(cont) • The Singleton Patternensures that a class only has one instance, and provide a global point of access to it.

30. The Factory Method<concept> • defines an interface for creating an object, but let subclasses decide which class to instantiate. • returns an instance of one of several possible classes depending on the data provided to it. • common parent, methods but different performance and optimized for different data • is tools used for simplifying tangled programming classes.

31. The Factory Method<concept > (cont) • Also Know as Virtual Constructor • structural Diagram

32. Sky Kimor Kim, Sky Name Factory First Name: Sky Last Name: Kim The Factory Method<Example> (cont) Input( First name comes first or last name comes first ) Factory analyze input and create right object and output. Output(first/last names are separated)

33. The Factory Method<Example: code> (cont) • Classes: super class: Namersub classes: FirstFirst, LastFirstFactory class: NameFactoryClient class: Driver

34. The Factory Method<Example: code: Functional Classes>(cont) • class Namer {protected String first, last; //store first, last name herepublic String getFirst() { return first; } //return first namepublic String getLast() {return last; } //return last name } Sub class create proper object class FirstFirst extends Namer { //split first last public FirstFirst(String s) { int i = s.lastIndexOf(" "); //find separating space if (i > 0) {first = s.substring(0, i).trim(); last =s.substring(i+1).trim(); } else { first = “”; // put all in last name last = s; // if no space }}} class LastFirst extends Namer { //split last, first public LastFirst(String s) { int i = s.indexOf(","); //find comma if (i > 0) {last = s.substring(0, i).trim(); first = s.substring(i + 1).trim();} else { last = s; // put all in last name first = ""; // if no comma }}}

35. The Factory Method<Example: code: Factory Classes>(cont) //returns an instance of LastFirst or FirstFirstdepending on whether a comma is found class NameFactory { public Namer getNamer(String entry) { int i = entry.indexOf(","); //comma determines name order if (i>0) return new LastFirst(entry); //return LastFirst object else return new FirstFirst(entry); // return FirstFirst object}}

36. The Factory Method<Example: code: Driver Classes>(cont) class Driver{ private void computeName() { NameFactory nfactory=new NameFactory(); //create Factory. //send the text to the factory and get a class back namer = nfactory.getNamer(entryField.getText()); System.out.println(“First Name: “+namer.getFirst()); System.out.println(“Last Name: “+namer.getLast()); }}

37. The Factory Method<When to use> • ·a class can’t anticipate which kind of class of objects it must create. • ·a class uses its subclasses to specify which objects it creates. • ·you want to localize the knowledge of which class gets created. • ·classes delegate responsibility to one of several helper subclasses, and you want to localize the knowledge of which helper subclass is the delegate.

38. The Abstract Factory Method<concept> • is one level higher abstraction than the Factory pattern. • is a factory object that returns one of several factories. • to provide an interface for creating families of related or dependent objects without specifying their concrete classes

39. The Abstract Factory Method<concept> • Use this pattern when you want to return one of several related classes of objects, each of which can return several different objects on request. • isolates the concrete classes that are generated and actual class names of these classes are hidden in the factory and need not be known at the client level at all. • may define all of the subclasses’ methods in the abstract class.

40. The Abstract Factory Method<Example in Java API> • Most language’s Look and Feel is done by this pattern. • .getSystemLookAndFeelClassName() method return proper LookAndFeel name. Various LookAndFeel classes are hidden encapsulated from Driver client class. class Driver{ public Driver(){ String laf = UIManager.getSystemLookAndFeelClassName(); try { UIManager.setLookAndFeel(laf); } catch (UnsupportedLookAndFeelException exc) {System.err.println("UnsupportedL&F: " + laf);} catch (Exception exc) {System.err.println("Error loading " + laf);} }}

41. The Abstract Factory Method<Example: Display/Print Drivers> • A computer system displays and prints shapes depending on the CPU speed and the memory size of the computer. • Different Driver for different machines

42. The Abstract Factory Method<Example: Display/Print Drivers>(cont) • Class abstraction hierarchy for drivers

43. The Abstract Factory Method<Example: Display/Print Drivers>(cont) • Middle level Machine may need High and Low resolution types • need class hierarchy regarding to High and Low resolution like following diagram

44. The Abstract Factory Method<Example: ResFactory>(cont) • two class hierarchies under the same classes: we have two factory considerations. • need to retrieve proper drivers regarding to Print/Display with High and Low resolution for both drivers. • need a factory class returns object regarding 2 class hierarchies. • How to put these together?: Abstract Factory Pattern is a good solution.

45. The Abstract Factory Method<Example: ResFactory>(cont) • structure of classes with Abstract Factory pattern

46. The Abstract Factory Method<Example: ResFactory code>(cont) abstract class ResFactory{ abstract public DisplayDriver getDispDrvr(); abstract public PrintDriver getPrtDrvr();}  class LowResFact extends ResFactory{ public DisplayDriver getDispDrvr(){ return new LRDD(); } public PrintDriver getPrtDrvr(){ return new LRPD();} }  class HighResFact extends ResFactory{ public DisplayDriver getDispDrvr(){ return new HRDD(); } public PrintDriver getPrtDrvr(){ return new HRPD();} }

47. The Abstract Factory Method<When to use> • The client object does not know which particular concrete implementations of the server objects it has because the factory object has the responsibility to create them. • The client object does not even know which particular factory it uses since it only knows that it has an Abstract Factory object. It has concrete factory classes implementing it, but it doesn’t know which one to use.

48. The Builder Pattern<Concept> • is used to separate the construction of a complex object from its representation so that the same construction process can create different representations. • The pattern assembles a number of objects to make a new object.cf) (Abstract) Factory Pattern return existing object without assembling objects. • The (Abstract) Factory Pattern returns factory made productwhile the Builder pattern returns custom made product.

49. The Builder Pattern<Concept: structure diagram> • Client request to Director • one abstract builder with several ConcreteBuilders • Director decides which builder will be used to build a result.

50. The Builder Pattern<Example: Burger store>