1. SE-2811 Software Component Design Week 1, Day 1 Design pattern defined Code that needs a design pattern… SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick 1

2. A design pattern is a general reusable solution to a commonly occurring problem in software design. – Dr. Urbain SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick 2

3. A design pattern is… A “standard” arrangement (structure) of certain classes that comprise a solution to a given problem Many different Patterns can appear in a single application During execution, the objects created from these classes interact in a specific way (behavior) to implement a specific function The same type of function that is typically needed by many types of applications SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick Slide credit: Dr. Urbain 3

4. Analogy 4 Problem In every house and every workplace there is a daily "traffic" of the objects which are handled most. Unless such things are immediately at hand, the flow of life is awkward, full of mistakes; things are forgotten, misplaced. Solution Build waist-high shelves around at least a part of the main rooms where people live and work. Make them long, 9 to 15 inches deep, with shelves or cupboard underneath. Interrupt the shelf for seats, windows, and doors. SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick Slide credit: Dr. Urbain

5. Analogy (cont.) 5 Waist high shelves are everywhere They look different Different materials Different colors Different dimensions Different names Yet, they solve a very important recurring problem. SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick Slide credit: Dr. Urbain

6. Consider a (badly written) generic Duck class //Duck daffy = new Duck(Duck.MALLARD, “daffy”); //Duck donald = new Duck(Duck.REDHEAD, “donald”); //Duck clyde = new Duck(Duck.DECOY, “clyde”);... public void swim() { if( type == REDHEAD || type == MALLARD ) // swim in circles else // swim randomly } public void quack() { if( type == MALLARD || type == REDHEAD ) // real ducks quack else // do nothing; decoys don’t quack } SE-2811 Dr. Mark L. Hornick 6 SimUDuck v1

7. Duck is an example of a class that exhibits low cohesion Cohesion: A measure of how focused or strongly related the responsibilities of a class are 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) SE-2811 Dr. Mark L. Hornick 7

8. Class Exercise With your neighbor for 3 minutes: Sketch a new design that solves this problem Quantity, not quality: Try to include as many details in your design as you can Use  a UML class diagram with just the key methods,  sketches about what code will go where  anything you want SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick 8

9. Refactoring to improve cohesion via use of OO Inheritance Duck: an abstract class Abstract classes can define attributes and (default) behaviors common to all Duck-derived classes. Concrete classes implement type-specific adaptations (overrides) These may also include additional type-specific attributes (none in this case) SE-2811 Dr. Mark L. Hornick 9 SimUDuck v2

10. Is inheritance always a solution? What if some ducks (Mallards, Redheads) had similar behavior: Quacking sound Circular swimming pattern While others (Pintail) had different behaviors: Quacking sound Random swimming (ie floating) pattern And still others (Decoys) had: No quacking sound Random swimming (ie floating) pattern Lots of overriding (and maybe duplication of code)! Q1) Should we bother implementing any behaviors at all in the Duck abstract class if many will be overridden anyway (and possibly duplicated)? Q2) Can we modify the class hierarchy to group similar behaviors together? SE-2811 Dr. Mark L. Hornick 10 Code duplication?

11. What about multiple levels of abstraction? SE-2811 Dr. Mark L. Hornick 11 Here, the swim() and quack() behavior is defined, but not implemented, in Duck… …instead, swim() and quack() behaviors are implemented in a second level of abstract classes... …and finally inherited in concrete classes. SimUDuck v3 And what about a quiet, swimming Duck?

12. BUT: Multiple inheritance is not even allowed in Java! (FYI: it IS allowed in C++, but is EVIL) SE-2811 Dr. Mark L. Hornick 12 Here, the swim() and quack() behavior is defined, but not implemented, in Duck… …instead, swim() and quack() behaviors are implemented in a second level of abstract classes... …and finally inherited in concrete classes. SimUDuck v3

13. This can also lead to messy “class explosions” SE-2811 Dr. Mark L. Hornick 13 SimUDuck v3

14. Some reflections on inheritance… Allan Holub (a noted computer technology author) once attended a Java user group meeting where James Gosling (Java's inventor) was the featured speaker. During the memorable Q&A session, he asked him [Gosling]: Q: "If you could do Java over again, what would you change?" Gosling: "I'd leave out classes.” After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship), Gosling explained, is preferable. SE-2811 Dr. Mark L. Hornick 14

15. We can use interface inheritance to address these concerns… SE-2811 Dr. Mark L. Hornick 15 We eliminate implementation in abstract classes, and force concrete classes to supply it instead. …but now we’re back to the duplication of code problem that we saw in v2! SimUDuck v4