CS352 – Software Engineering II Lecture 7: Design Patterns V

1. CS352 – Software Engineering IILecture 7: Design Patterns V Review Slides from CS251 SE I http://www.acadox.com/join/24VZEM http://www.acadox.com/class/3962

2. Overview of This Lecture • Design Patterns: • Introduction to SW Design Patterns • Review of Observer Pattern • Player-role Pattern • State Pattern • Strategy Pattern • Java GUI Model

3. Design Pattern: Introduction • There are recurring/characteristic problems during a design activity. • E.g., A certain class should have only one instance. • Known as Pattern. • Designers come up with various solutions to deal with these problems. • Eventually, best known solutions are collected and documented as DesignPatterns.

4. Design Pattern: Definition • A Design Pattern is the outline of a reusablesolutionto a general problem encountered in a particular context: • describes a recurring problem • describes the core of the solution to that problem. • Design Patterns are namedto facilitate people using and discussing them.

5. Design Pattern: Usefulness 1.Reuse existing, high-quality solutionsto recurring design problems. 2.Improve future design: Solutions to new problems can be obtained with higher quality. 3. Shift the level of thinking to a higher perspective. 4. Use common terminology to improve communicationswithin team members. 5.Improve documentation: smaller, simpler. 6. Use a right design, not just one that works. 7. Studying patterns is an effective way to learn from the experience of others.

6. Pattern Categories • Gamma, Helm, Johnson, Vlissides: (Gang of Four, 1995) presented 23design patterns in 3 categories: 1. Creational: Creation of objects. Separate the operations of an application from how its objects are created. 2. Structural: Concern about the composition of objects into larger structures. To provide the possibility of future extension in structure. 3. Behavioral: Define how objects interact and how responsibility is distributed among them. Use inheritance to spread behavior across the subclasses, or aggregation and composition to build complex behavior from simpler components.

7. GoF: Design 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 / Player-role Strategy Template Method Visitor

8. Pattern Description Format • Context: • The general situation in which the pattern applies. • Problem: • The main difficulty to be tackled. • Criteria for a good solution. • Solution: • Recommended way to solve the problem. • Antipattern (optional): • Erroneous or inferior solution. CPSC-4360-01, CPSC-5360-01, Lecture 8

9. CPSC-4360-01, CPSC-5360-01, Lecture 8

10. 1- The Player-Role Pattern • Context: • A role is a particular set of properties associated with an object in a particular context. An object may play different roles in different contexts. • Example: • A Student can be either part time or full time, and can change from one to another. • Problem: • Find the best way to model players and roles so that a player can change roles or possess multiple roles. • We want to avoid multiple inheritance. • We cannot allow an instance to change class. CPSC-4360-01, CPSC-5360-01, Lecture 8

11. Player-Role • Solution: • Create a class <<Player>> to represent objects that play roles. • Create an association from this class to an abstract <<Role>> class, a super-class of all possible roles. • Subclasses of <<Role>> encapsulate the properties and behaviors with different roles. • Multiplicity can be one-to-one or one-to-many. CPSC-4360-01, CPSC-5360-01, Lecture 8

12. <<Player>> <<AbstractRole>> <<Role1>> <<Role2>> Student AttendanceRole FullTime PartTime The Player-Role Pattern • Solution: General Idea Applied to the student example. CPSC-4360-01, CPSC-5360-01, Lecture 8

13. Student • role : int • + method () Student FullTime PartTime Anti Player-Role Pattern { if (role == 1) …. } • Inferior (not so good) Solution: Put role as an attribute Inherit from Student Class

14. CPSC-4360-01, CPSC-5360-01, Lecture 8

15. The State Pattern • Context: • An object exhibits different behavior. When its internal state changes, the object appears to have changed its class at run time. • Problem: • Allow different behaviors without actually changing the class of an object. • State changing should be decided by the current behavior. • Should allow only one behavior at any time. CPSC-4360-01, CPSC-5360-01, Lecture 8

16. The State Pattern. Solution • There are applications that request an object to alter its behaviour when its internal state changes, e.g., if a class is described by a state-chart. • Solution: represent each state by a separate class. • each state class will implement the appropriate behaviour for each operation in that state only. • A consequence of this pattern is that the state classes need access to the internal details of the context class.

17. 1 <<Class>> <<AbstractState>> state request( ) handle( ) <<State1>> <<State2>> handle( ) handle( ) 1 CDPlayer CDPlayerStates myState play( ) play( ) Opened Playing Close play( ) play( ) play( ) The State Pattern • Solution: General Idea: { state.handle( ); } Applied to the CD Player Example. { myState.play( ); }

18. Example – TCPConnection class • A TCPConnection object can be in one of several different states, established, listening or closed. • The behavior of TCPConnection is different in each of these three states.

19. Example – TCPConnection class TCPState TCPConnection Open() Close() Acknowledge() Open() Close() Acknowledge() state->Open() TCPEstablished TCPListen TCPClosed Open() Close() Acknowledge() Open() Close() Acknowledge() Open() Close() Acknowledge()

20. Example – TCPConnection class • TCPConnection maintains a state object which is a subclass of TCPState. • When the connection changes state the TCPConnection object changes the state object it uses.

21. CDPlayer myState play( ) The State Pattern • Antipattern: • Code all the behaviors in one class, and make use of if-then-else or switch to decide what is the correct response. { if (myState == OPEN) ... else if (myState == CLOSED) ... else if (myState == PLAYING) ... }

22. Comparison: Player-Role and State Patterns • Similarities: • <<Player>> is replaced by <<Class>> • <<AbstractRole>> is replaced by <<AbstractState>> • <<State1>>, … are replaced by <<Role1>>, … • Differences: • The change of <<Role>> is decided by the <<Player>> instead of depending on the <<Role>>; • The change of <<State>> is decided by the <<State>>. • Hence it is a two-ways relation and a state needs to have a link to its class to be able to change its state

24. The Strategy Pattern • Context: • Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it. • Problem: • Allow different behaviors without actually changing the class of an object. • Strategy / Algorithm change as needed within the same class

25. The Strategy Pattern. Solution • Solution: represent each strategy by a separate class. • each strategy class will implement the appropriate algorithm • At run time, a class can change its strategy

26. The Strategy Pattern • Solution:

27. The Strategy Pattern: Applicability • Many related classes differ only in their behavior • You need different variants of an algorithm • An algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures. • A class defines many behaviors, and these appear as multiple conditional statements in its operations. • Instead of many conditionals, move related conditional branches into their own Strategy class

28. The Strategy Pattern: Example • Solution:

29. Example – Java GUI • Solution:

30. Example – Java GUI • Situation: A GUI container object wants to decide at run-time what strategy it should use to layout the GUI components it contains. • Many different layout strategies are already available. • Solution: Encapsulate the different layout strategies using the Strategy pattern! • This is what the Java AWT does with its Layout Managers!

31. Example – Java GUI • Sample Code: • Frame f = new Frame(); • f.setLayout(new FlowLayout()); • f.add(new Button(“Press”)); • http://docs.oracle.com/javase/tutorial/uiswing/layout/

32. CPSC-4360-01, CPSC-5360-01, Lecture 8

33. Top 10 Books Programmers Read • Code Complete by Steve McConnell (2E, 2004). • The Pragmatic Programmer by Andrew Hunt and David Thomas (1999). • Structure and Interpretation of Computer Programs by Abelson, Sussman, and Sussman (2E, 1996). • The C Programming Language by Brian Kernighan and Dennis Richie. CPSC-4360-01, CPSC-5360-01, Lecture 8

34. Top 10 Books Programmers Read • Refactoring: Improving the Design of Existing Code by Martin Fowler, Kent Beck, John Brant, and William Opdyke (1999). • Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, and Vlissides (1994). The "Gang of 4" book. • The Mythical Man-Month by Frederick Brooks (1995). CPSC-4360-01, CPSC-5360-01, Lecture 8

35. Top 10 Books Programmers Read • The Art of Computer Programming, Volume 1: Fundamental Algorithms (3rd Edition, 1997) by Donald Knuth. • Compilers: Principles, Techniques and Tools 2E by Aho, Lam, Sethi, and Ullman (2006). CPSC-4360-01, CPSC-5360-01, Lecture 8

36. Other Highly Praised Books • Other Highly Praised Books • Clean Code by Robert Martin, a lot in common with Code Complete. • Effective C++ and More Effective C++ by Scott Mayers. • Effective Java 2E by Joshua Bloch. • CODE: The Hidden Language of Computer Hardware and Software. CPSC-4360-01, CPSC-5360-01, Lecture 8