1. In the “real world” we’re taught that design is pretty. Here we learn that design is about productivity. Introduction to Software Design 1

2. Introduction to Design Concepts and Diagnosis 2

3. Some things we’d like to be true Mostly about easing CHANGE  Easy to find what code to modify to add a feature  …I only have to modify one class (in addition to writing the new code)  …It’s easy to understand the class I have to change  …My teammate can add another feature without us colliding or stopping working to talk  …When I test my code, nobody else’s code needs to work Good software design gets us close to these ideals 3

4. First, Diagnosis  We can’t cure the patient until:  We know what’s wrong  Just how healthy s/he can be  So, before I teach you how to design  Let’s take a look at:  What some bad designs looks like  What some good designs looks like 4

5. Two Diagnostics for Good Design  S ingle R esponsibility P rinciple ( SRP )  Each class should be responsible for one thing (capability, entity, computation, etc.)  Can phrase this as “mind your own business”  object do its own calculations  object should not do calculations for another  Easy to violate this because objects need to be connected to one another  e.g., Events happen as part of Dates  D on’t R epeat Y ourself ( DRY )  Each computational idea should be expressed just once  Violations often the result of  cut-and-paste programming  incomplete class (others have to do calculations for it, which also violates SRP)  But also over-specialization of classes (class = object)

6. A Concise Theory of Object-Oriented  Object represents a “thing”  person, car, date, …  (not two things, not ½ thing)  Object responds to messages  (method calls)  Things it does to itself (SRP)  That is, other objects ask the object to do something to itself  Objects are “opaque”  Can’t see each others’ data/vars  Messages (calls) are only way to get things done 6

7. A Concise Theory of Object-Oriented, II  Because objects are completely opaque, we don’t need to know what’s really inside them  Each car object could be implemented with its own unique code  If two cars behave the same, then really should have same code  Otherwise would violate DRY  And a huge amount of coding work  So all cars are made from a common car template  Template = class  The car template is not a car, it’s a “blueprint” for a car  Helps satisfy DRY 7

8. So OO Design is easy, right? Uh, no. Tendency is to cram “related” functionality into existing classes, rather than creating new ones 8

9. SRP design has classes for “doers” 9

10. So OO Design is easy, right? No. (pt II) A related challenge is when two classes closely collaborate, like the iSwoon Date & Event classes 10

11. Example: iSwoon Repetition (violates DRY)

12. Example: iSwoon (continued) 12 This code violates SRP. Why? A. reuses the responsibility of which events go with which date B.it checks validity of events and also stores list of events Better phrasings: A.Date does not “validates-events itself” B.Changes to Event (like adding new event type) requires changing Date

13. Example: iSwoon (continued) 13 Responsibility for Events (violates SRP) Also note that the only difference between subclasses is a constant data value Not just calling event method (that’s OK), but calculating on event data to derive event property

14. 14 Repetition (violates DRY) Also note that only difference in subclasses is a constant

15. Refactored iSwoon Design Replaces 3 Event constructors No class for each date!

16. Refactored iSwoon Design (cont’d) 16 Moved from Date to get SRP. “Factory” Methods keep Event details local No class for each event!

17. Refactored iSwoon Design (cont’d) 17 But now date functionality here! Why OK? Why is it OK to have dateSupported(int) in Event, but not validateEvent(Event) in Date? A. Because whether an Event is allowed is a property of the Event itself, not the Date B. The only thing that’s going to use a Date is an Event C. Dates are hard numbers, while events are flexible D. You wouldn’t have to change bit of code if you were to add another valid Event

18. Refactored iSwoon Design (cont’d) 18 But now date functionality here! Why OK? Why is it OK to have dateSupported(int) in Event, but not validateEvent(Event) in Date? My answers: A.dateSupported is checking the appropriateness of an individual Event for how mature the relationship is (not about the ordering of selected events) B.Said another way: Date class is about the ordering of selected Events for a date (not event validity) C.dateSupported is computing on an int, not a Date

19. People are Complicated Consider this Java class, which is using good naming conventions to convey the meanings of the methods: class Person { public void rainedOn (); public boolean isWet (); public String getSpouseName (); public boolean isLeftHanded (); } Which methods are SRP? A. rainedOn(), isLeftHanded() B. isWet(), getSpouseName() C. isWet(), isLeftHanded() D. getSpouseName(), isLeftHanded() 19

20. Design Diagnosis Review  Three common mistakes in design  TOO MUCH : Put all X-related functionality in class X (Automobile)  TOO FRIENDLY : Blending of closely related classes (Date & Event)  TOO LITTLE : Defining object-like classes (Date & Event)  A few diagnostic techniques  SRP : do the “____ itself” test on methods  SRP: a change in one class causes change in another class  DRY : repetitive code  DRY : A “small” change requires many similar changes across methods or classes  Constant Classes : Only diff. between classes is constants (same methods)  Repairs to design  For non-SRP functionality  Create additional classes, move there (Automobile)  Move into existing classes (Date & Event)  DRY: Create new method out of repetitive code, call it  Merge repetitive, similar classes and encode differences with variables 20

21. Take-Aways from Class Today  Object-oriented design is intuitive, but subtle  Java is just a tool, does not guarantee good design  (Just because I have an expensive camera does not make me a good photographer :)  Easy to put functionality in wrong place, make classes too big, or make too small  Possible to diagnosis and repair a design before or after the coding (may require both)  SRP, DRY  Change in one class affects another (SRP)  Small change affects multiple classes or methods  Unfortunately, there are many kinds of design mistakes, and unique repairs for them 21

22. Quiz set-up  Hats off (brims and hoods)  Technology and notes put away  On your desk  Single piece of standard-sized paper  pen/pencil  eraser if you like, but faster to scratch out  About your paper  Name and student ID on paper  Eyes on your own paper  Protect your paper  Turn over after done checking your answer  If you have a question, raise your hand and we’ll come over 22

23. Quiz 1.Suppose your team’s velocity is 0.6 : Your Iteration length is 10 days and you have 6 people on your project. How much actual work, measured in person-days, can your team complete? (Show your calculation.) 2.If Tasks are useful because they are smaller than User Stories, why not just skip User Stories and write-up Tasks? (Explain.) 3.Translate the following requirements into user stories (omit estimates and priorities): I want a chat client in which I can send messages to a given buddy, as well as to all users who have the variable openFlag set to TRUE. 23

24. Discussion Notes  Suppose your team’s velocity is 0.6 : Your Iteration length is 10 days and you have 6 people on your project. How much actual work, measured in person-days, can your team complete? (Show your calculation.) 10 days * 6 people * 0.6 = 36 people-days 24

25. Discussion Notes  If Tasks are useful because they are smaller than User Stories, why not just skip User Stories and write-up Tasks? (Explain.) User stories are written in the customers language to facilitate communication, whereas Tasks are written in technical language, which is not familiar to the customer. 25

26. Discussion Translate the following requirements into user stories (omit estimates and priorities): I want a chat client in which I can send messages to a given buddy, as well as to all users who have the variable openFlag set to TRUE. Have a feature to set the user’s variable to true or false. Allow users to receive messages from non-buddies. Create the ability to send messages to users/buddies (touch of task language) The user should have the ability to list all the users who want to chat Users have the ability to create profiles (buddy list) User should be able to send messages to their buddies and anyone else… 26

27. But design is time-consuming HFSD fights the high cost of design in many ways  TDD : use-driven, simple design  Refactoring : fix design only when needed  Good-Enough Design : make it better, not perfect 27

28. Good-Enough is the “ 80/20 Rule ”  Returns on engineering investment are not linear  80 percent of the benefit for 20% of the effort  Diminishing returns for investment after that (other 80% of effort and only 20% gain)  Also known as Pareto Principle 28 small effort big gain

29. Good-Enough Design On time because you design fast and can code fast 29 Bad design will make you late. Perfect design will make you late. So make your design good enough

30. Software Engineers (aka developers) What’s the difference between a software engineer and a programmer? A. B. C. D. 30

31. Extreme Programming (XP)  HFSD is Scrum management with Agile devel. practices  Mix terminology, too (Scrum calls Iteration a “Sprint”)  XP, much like HFSD, but…more extreme  Some expansions on what we’ve done so far  On-site customer  Deliver continuously (but still have iterations, shorter)  40-hour work week  Some other extremes  Pair programming  “Courage”  Some things the same  User stories  Daily Stand-up meeting  Test-first (Thursday) 31

32. XP vs. Scrum Given that XP is less planned and more iterative than Scrum, when would you favor an XP-style software process? A. B. C. D. 32