SE-2811 Software Component Design

1. SE-2811Software Component Design • Week 1, Day 2 • Making teams • Warm-up exercise • Design pattern defined SE-2811 Dr. Josiah Yoder Slide style: Dr. Hornick

2. Consider a program that draws arbitrary shapes: SE-2811 Slide credit: Dr. Mark L. Hornick

3. Q: What attributes would you define? SE-2811 Slide credit: Dr. Mark L. Hornick

4. 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

5. 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

6. Analogy 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

7. Analogy (contd.) • 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

8. 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 // do nothing; decoys just float } public void quack() { if( type == MALLARD || type == REDHEAD ) // real ducks quack else // do nothing; decoys don’t quack } SE-2811 Dr. Mark L. Hornick SimUDuck v1

9. 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

10. 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 SimUDuck v2

11. 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? Code duplication? SE-2811 Dr. Mark L. Hornick

12. What about multiple levels of abstraction? 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. And what about a quiet, swimming Duck? SE-2811 Dr. Mark L. Hornick SimUDuck v3

13. BUT: Multiple inheritance is not even allowed in Java!(FYI: it IS allowed in C++, but is EVIL) 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. SE-2811 Dr. Mark L. Hornick SimUDuck v3

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

15. 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

16. We can use interface inheritance to address these concerns… 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! SE-2811 Dr. Mark L. Hornick SimUDuck v4

17. 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