1. SE-2811 Software Component Design
1/13/2019
SE-2811 Software Component Design
Week 1, Day 2 (and perhaps 1-3 and 2-1)
Print
SE-2811
Dr. Josiah Yoder
Slide style: Dr. Hornick
Dr. Josiah Yoder

2. Review What problems are we trying to avoid?
SE-2811
1/13/2019
Review
What problems are we trying to avoid?
What do we want to achieve?
SE-2811
Dr. Mark L. Hornick
Dr. Josiah Yoder

3. SE-2811
1/13/2019
Review: 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
Dr. Josiah Yoder

4. The Duck App in Code – v0 (review)
SE-2811
1/13/2019
The Duck App in Code – v0 (review)
SE-2811
Dr. Josiah Yoder
Slide style: Dr. Hornick
Dr. Josiah Yoder

5. Applying the Strategy Pattern: Action! (Code v5) (Review)
SE-2811
1/13/2019
Applying the Strategy Pattern: Action! (Code v5) (Review)
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
Dr. Josiah Yoder

6. Slide style: Dr. Hornick
SE-2811
1/13/2019
The constructor for V5
public Duck(String name, String imageFile, SwimBehavior sb, QuackBehavior qb) { this.name = name; loadDuckImage(imageFile); swimmingBehavior = sb; quackingBehavior = qb; …
SE-2811
Dr. Josiah Yoder
Slide style: Dr. Hornick
Dr. Josiah Yoder

7. Creating Ducks with specific behaviors: Fill in the blank
SE-2811
1/13/2019
Creating Ducks with specific behaviors: Fill in the blank
// create some behaviors SwimBehavior csb = new CircularSwimming(); QuackBehavior sqb = new StandardQuacking(); SwimBehavior rsb = new RandomFloating(); // daffy has circular swimming, std quacking Duck daffy = ____________________________ // donald has random floating, std quacking Duck donald = ___________________________ daffy.swim(); donald.quack();
SE-2811
Dr. Mark L. Hornick
Dr. Josiah Yoder

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

9. Inside a Waterfowl class
SE-2811
1/13/2019
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
Dr. Josiah Yoder

10. Strategy is a Behavioral Design Pattern
SE-2811
1/13/2019
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!
Dr. Josiah Yoder

11. The Strategy pattern favors Encapsulation over Extension
1/13/2019
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.
Dr. Josiah Yoder

12. A good Design Pattern has also solved a larger conceptual issue:
SE-2811
1/13/2019
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
Dr. Josiah Yoder

13. Coupling: How closely two or more classes are related
1/13/2019
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
Dr. Josiah Yoder

14. Cohesion: How focused the responsibilities of a class are
1/13/2019
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
Dr. Josiah Yoder

15. SE-2811
1/13/2019 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
Dr. Josiah Yoder

16. SE-2811
1/13/2019 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
Dr. Josiah Yoder

17. Other design principles benefitting from the Strategy Pattern
SE-2811
1/13/2019
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
Dr. Josiah Yoder

18. Other good design principles we visited
SE-2811
1/13/2019
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”)
Dr. Josiah Yoder

19. Access Modifiers (bullets)
SE-2811
1/13/2019
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 protected to allow derived classes in any package access to members
Use /*package*/ if cooperating classes in the same package need access to attributes or special methods
Use private to completely guard members from view outside the defining class
Dr. Josiah Yoder

20. Access Modifiers (table)
SE-2811
1/13/2019
Access Modifiers (table)
Access Levels
Modifier
Class
Package
Subclass
World
public Y
protected N
/*package*/
private
Adapted from Oracle’s Java tutorial
SE-2811
Dr. Mark L. Hornick
Dr. Josiah Yoder

21. Slide style: Dr. Hornick
[Class ended here]
SE-2811
Dr. Josiah Yoder
Slide style: Dr. Hornick

22. Are there disadvantages?
SE-2811
1/13/2019
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
Dr. Josiah Yoder

23. Sorting Example Suppose we have a program that sorts Class objects
1/13/2019
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
Dr. Josiah Yoder

24. A Strategy for Comparing [Collections.sort()]
SE-2811
1/13/2019
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
Dr. Josiah Yoder

25. 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:

26. The Strategy Design Pattern in its general form:
SE-2811
1/13/2019
The Strategy Design Pattern in its general form:
The Context is the class that encapsulates and uses a specific behavior, or Strategy.
A Strategy is an interface that defines a behavior
ConcreteStrategy classes implement specific behaviors
Dr. Josiah Yoder