SE-2811 Software Component Design

1. SE-2811Software Component Design • Week 1, Day 2 (and 1-3 and 2-1) SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick

2. Guest Lecture Monday • Visitor from Rockwell Collins • Will speak on “real work” • Please respect our visitor by coming to class and paying attention. • If you want to use your laptop for taking notes on the visitor’s talk, please email me your notes after the lecture. SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick

3. Review What problems are we trying to avoid? What do we want to achieve? SE-2811 Dr. Mark L. Hornick

4. A different approach: Isolate behaviors that vary, and encapsulate them as attributes to eliminate implementation inheritance and class explosions: SE-2811 Dr. Mark L. Hornick SimUDuck v5

5. Sorting Example • Suppose we have a program that sorts Class objects • Perhaps alphabetically, perhaps by “closeness of fit” • Perhaps using Bubble Sort, or a (much better) algorithm like Merge Sort. SE-2811 Dr. Mark L. Hornick

6. A Strategy for Comparing [Collections.sort()] Collections.sort() implements an argument which is a reference to a concrete class that implements the Comparator interface, and thus the behavior of the compare() method. Depending on the strategy of the compare() method in the concrete class, different sorting will be used by Collections.sort(). The comparison strategy is decoupled from the Collections.sort() method itself. SE-2811 Dr. Mark L. Hornick

7. A Strategy for Sorting • Different strategies for sorting • MergeSort O(NlogN) • QuickSort O(NlogN) • ShellSort In-place, Ω(N(logN/log logN)2) • InsertionSort O(N2) • BubbleSort  O(N2) • Cool sorting algorithms of the future (or past) … • Would be nice to “plug in” new strategies SE-2811 Dr. Josiah Yoder Idea: http://fuchangmiao.blogspot.com/2007/10/strategy-vs-observer.html

8. The Strategy Design Patternin its general form: The Context is the class that encapsulates and usesa specific behavior, or Strategy. A Strategy is an interfacethat defines a behavior ConcreteStrategy classes implement specific behaviors

9. The Duck App in Code – v0 SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick

10. Applying the Strategy Pattern: Evidence 1 The Strategy Pattern is a behavioral pattern usually considered and applied at design-time. Premise: Your application requires similar objects whose behavior varies. SE-2811 Dr. Mark L. Hornick

11. Applying the Strategy Pattern: Evidence 2 As a designer, you watch for inheritance patterns that result in excessive behavior overrides and/or code duplication among classes. SE-2811 Dr. Mark L. Hornick

12. Applying the Strategy Pattern: Action!(Code v5) Leave behavior that is truly shared in abstract classes. Isolate behavior(s) that vary and declare interfaces that define those behaviors Implement the behaviors in separate concrete classes whose references can be passed to the Duck ctor SE-2811 Dr. Mark L. Hornick

13. Creating Ducks with specific behaviors // create some behaviors SwimBehavior csb = new CircularSwimming(); QuackBehavior sqb = new StandardQuacking(); SwimBehavior rsb = new RandomFloating(); // daffy has circular swimming, std quacking Waterfowl daffy = new Duck(“daffy”, csb, sqb); // donald has random floating, std quacking Waterfowl donald = new Duck(“donald”, rsb, sqb); daffy.swim(); donald.quack(); SE-2811 Dr. Mark L. Hornick

14. Inside a Duck class // constructor public void Duck(String name, SwimBehavior sb, QuackBehavior qb) { super(name, sb, qb) } SE-2811 Dr. Mark L. Hornick

15. Inside a Waterfowl class public abstract class Waterfowl { private SwimBehavior swimBehavior; private QuackBehavior quackBehavior; private String name; // constructor public void Waterfowl(String name, SwimBehavior sb, QuackBehavior qb) { this.name = name; swimBehavior = sb; quackBehavior = qb; } // centralize implementation of behaviors in top-level classes // if possible; avoid duplication of behavior in subclasses. // Note we can make this method final to prevent subclasses from overriding it! public void swim() { swimBehavior.swim(); // invoke the specific behavior } ... SE-2811 Dr. Mark L. Hornick

16. Strategy is a Behavioral Design Pattern The Strategy pattern allows for selection of specific behavioral algorithms at runtime, since the selected strategy is just an attribute of the class using the Strategy. • We can select particular behavioral strategies when we construct the Ducks • But since the swim() or quack() behaviors of Duck are just attributes (references) to concrete Strategy classes, we could easily change the behaviors at any time with a simple setSwimBehavior() mutator method!

17. The Strategy pattern favors Encapsulation over Extension • That is, rather than changing the behavior implemented within a derived class by extending from a parent/base class, we encapsulate behaviors into a class as instance attributes, which can be varied. • The Strategy pattern lets us vary and change behavioral algorithms independently of the clients that use the behaviors.

18. A good Design Pattern has also solved a larger conceptual issue: To make a program easy to maintain, we always want to strive for • High cohesion • Low coupling SE-2811 Dr. Mark L. Hornick

19. Coupling: How closely two or more classes are related Does one class refer to features from another class several times? • If “yes”, then it has high coupling (bad) • If no, then it has low coupling (good) changes to the Duck class (low coupling) SE-2811 Dr. Mark L. Hornick

20. Cohesion: How focused the responsibilities of a class are Cohesion: Does a class do many unrelated things? If “yes”, then it has low cohesion (bad) Does a class represent only one thing? If “yes”, then it has high cohesion (good) • Some definitions from previous students: • Few behaviors in a class • Each class should have one focus SE-2811 Dr. Mark L. Hornick

21. Q1 • A Duck class that swims, quacks, and displays itself exhibits (pick the best choice) • Low cohesion • High cohesion • Low coupling • High coupling SE-2811 Dr. Mark L. Hornick

22. Q2 • Mallard, Redhead, Decoy, and Mute duck classes that each implement similar quacking methods exhibit (pick the best choice) • Low cohesion • High cohesion • Low coupling • High coupling SE-2811 Dr. Mark L. Hornick

23. Other design principles benefitting from the Strategy Pattern • increases cohesion, but (in this case) increases coupling • The behavior of the Duck is not coupled to the Duck – behaviors are implemented separately. • Like all Design Patterns, the Strategy pattern allows us to vary a part of the system (swim and quack behavior) independently of other parts

24. Other good design principles we visited • Code to the highest level of abstraction that is possible in a given context: • ArrayList<Thing> = new ArrayList<Thing> // bad • List<Thing> = new ArrayList<Thing> // good • Collection<Thing> = new ArrayList<Thing> // better (“Programming to an Interface”)

25. Access Modifiers (bullets) • Code to most restrictive level of access modification that is possible in a given context: • Use public for constants and methods; never for attributes. On methods: only on those you want to support for public consumption • Use /*package*/ if cooperating classes in the same package need access to attributes or special methods • Use protected to allow derived classes in any package access to members • Use private to completely guard members from view outside the defining class

26. Access Modifiers (table) • Adapted from Oracle’s Java tutorial http://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html SE-2811 Dr. Mark L. Hornick

27. Are there disadvantages? • Yes: the implementation of the Strategy Pattern is somewhat more complicated than using inheritance • All design patterns usually exhibit this type of tradeoff. SE-2811 Dr. Mark L. Hornick