Docstoc

Chapter5

Document Sample
Chapter5 Powered By Docstoc
					Software Engineering
Christian Roberson
Slides based on material from Dan Pilone and Russ Miles

Getting It Done With Great Design
• Good design helps you deliver • Bad design can make life hard for everyone
Well, he’s not perfect, but he’s here, and sometimes that’s good enough…

• We will learn how to refactor your design, and how to apply the principles of good design. We’ll also learn how to handle unplanned tasks

iSwoon Is In Serious Trouble

Bob’s change needs refactoring and now Starbuzz wants a demo

Implications of Bob’s Change
• What has to change if?
– You needed to add three new types of events?
– You needed to add a new event called “Sleeping Over,” but it was only allowed on the third date? – You changed the value of the name attribute in OrderFlowersEvent to “SendFlowers”?

This Breaks the Single Responsibility Principle
Wow that’s not good…a single change means messing with a bunch of classes. Can’t we do something about that in our design?

• Single responsibility principle (SRP)
– Every object in the system should have a single responsibility, and all the object’s services should be focused on carrying out that single responsibility

• You implemented SRP correctly when each class only has one reason to change • Both the Date and Event class break this rule

SRP FAIL!
Date class handles if events are appropriate for a date

Must change when adding new events

Date classes must know this and change it if it changes

Spotting Multiple Responsibilites
1. On a sheet of paper, write down a bunch of lines like this: The [blank] [blanks] itself. You should have a line like this for every method you are testing. 2. In the first blank line, write down the class name. In the second blank, write down one of the class methods. Do this for each method. 3. Read each line out loud (tweak letters as needed to make it make sense). Does what you said make sense? Does your class really have the responsibility that the method indicates it does?

SRP Analysis for Automobile
Follow s SRP
The Automobile start[s] itself

Violate s SRP

The Automobile stops[s] itself

The Automobile changesTires itself

The [blank] [blanks] itself
The Automobile drives[s] itself Who drives the automobile? A

SRP Analysis for Automobile
Follow s SRP
The Automobile wash[es] itself

Violate s SRP

The Automobile check[s] oil itself

The Automobile gets[s] oil itself What does this mean? It gets the amount of oil, which a car object should do.

The [blank] [blanks] itself

SRP…Ur Doin’ It RIGHT!!

There Are No Dumb Questions
• How does SRP analysis work when a method takes parameters, like wash(Automobile) on the CarWash class?

• Good question! For your SRP analysis to make any sense, you need to include the parameter of the method in the method blank. So you would write “The CarWash washes [an] automobile itself”. It makes sense so it should stay.

There Are No Dumb Questions
• But what if CarWash took in an Automobile parameter as part of its constructor, and the method was just wash()? Wouldn’t SRP give us the wrong result? • It would. If a parameter that might cause a method to make sense, like an Automobile for wash() method on CarWash, is passed into the constructor, it could be misleading. Use common sense liberally.

Your Design Should Be DRY
• DRY is Don’t Repeat Yourself
– Avoid duplicate code by abstracting or separating out things that are in common and placing them in a single location

• DRY is about having each piece of information and behavior in your system in a single, sensible place.

DRY FAIL!

These are all almost identical code

There Are No Dumb Questions
• SRP sounds a lot like DRY. Aren’t both about a single class doing the one thing it’s supposed to do?

• They are related and can appear together. DRY is about putting functionality in a single place; SRP is making sure a class only does one thing. In welldesigned applications one class does one thing, does it well, and no other classes share that behavior.

There Are No Dumb Questions
• Isn’t having each class do only one thing kind of limiting? • It isn’t if that one thing is a big thing. The Event class only holds a name right now, but could also handle times, dates, notifications, alarms, addresses, etc. This is all still related to one thing. Only doing Event stuff would make this follow the SRP.

There Are No Dumb Questions
• And using SRP will help my classes stay smaller, since they’re only doing one thing right? • Actually, SRP often makes your classes bigger. Since you are not making several smaller classes, you may put more things into a single class. However SRP usually results in fewer classes, which can make the project easier to manage and maintain.

There Are No Dumb Questions
• I’ve heard of something called cohesion that sounds a lot like this. Are cohesion and SRP the same thing?

• Cohesion is just another name for SRP. If you are writing highly cohesive software, then you’re correctly applying SRP.

Small Tangent

Dates and Events Refactored
Only one date class is needed An event knows when it is allowed Description is now an attribute

Dates know their number and handle adding Events

When a date is added, it called dateSupported(), letting Events deal with event issues

Only one event class is needed

Post-Refactoring Standup Meeting
• Mark: So, it’s halfway through week 3, how are we doing? • Bob: Got it all done, we now have a really flexible piece of software that can support any number of different types of dates and events. • Laura: That’s great! Sounds like the extra work might pay off for us; we’ve got a ton of new events to add…

Post-Refactoring Standup Meeting
• Bob: Oh, it will. Now we can write just one or two lines of code and, BOOM, the new event is in the system. We allowed between two and five days for each event, and now it only takes a day, at most. • Mark: You’re not kidding. I’ve already added all the new events. And I’m sure we could make some more improvements as well…

Post-Refactoring Standup Meeting
• Laura: Wait just hang on a sec. For now the software is MORE than good enough, actually. Let’s not start making more changes just because we can. • Mark: So what’s next? • Bob: Well, now that I’ve got the refactoring done, it looks like we have some time to focus on the demo that the Starbuzz CEO wanted…

There Are No Dumb Questions
• When Laura says that the code is good enough, what does she mean? • Good question! We’ll talk a lot more about testing later in the course and how you can be confident and prove that your code does what it should.

Refactor This

BJD Task 7 Create Send Flowers event that contains the address and flower order E=2 Thanks to the new design, these can all be one in one day instead of seven LUG Task 10 Create a “Book Restaurant” event class E=3

Task 15 Add order cab event

MDE

E=2

Almost Got Burned
44 34 39 36 32

31

Work Left

20

15

10 Days Left

5

0

Plan For The Unplanned
User stories In Progress Complete Burn Down

Next

Must…demo…coffee …
Completed

Unplanned tasks on the board become planned

Demo
• Don’t forget to estimate the demo itself in your task • Always make a COMPLETE estimate.
Look! More unplanned tasks, YAY!

Nice…can you email me the minimum requirements? And does it work on Safari and Firefox, too? I want to start spreading the word to our customers right away.

Starbuzz CEO, now a happy iSwoon partner

End Of The Iteration
User stories In Progress Complete Burn Down

Next

Unfinished stories are shifted to the next iteration
Completed

Everything you accomplished

Final Burn Down
44 34 39 36 32

31

20 Work Left

You had one task left, but that is pretty close

3
0

20

15

10 Days Left

5


				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:12
posted:12/16/2009
language:English
pages:30