1 / 21

HFOOAD Chapter 3

This chapter explores the changes needed to add hardware and implement a bark recognizer to the existing dog door system. The code is modified and tested to incorporate these changes.

pmeyers
Download Presentation

HFOOAD Chapter 3

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. HFOOAD Chapter 3 Change: the constant in software development

  2. Change happens! Environment changes Maket changes Programs evolve And you’re responsible for changing your programs

  3. Great dog door, but… Can you add some hardware to recognize Fido’s bark when he wants go to out and come back in and automatically open the door? That way we don’t need to hear him or find that darn remote that keeps getting lost.

  4. What might change? 1 2 Hardware (new and modified) 3 The use case 4 The code (implementation and tests) …

  5. The old scenario Gina, open the dog door…Fido won’t quit barking! Woof! Woof! Woof! Woof! I feel much better now! Fido barks to be let out. 1 The door shuts automatically. 6.1 Todd or Gina hears Fido barking. 2 The dog door opens. 4 Todd or Gina presses the button on the remote control. 3 Fido goes outside. 5 Fido barks to be let back inside. 6.2 Again with the barking! Someone let Fido back inside Fido does his business. 6 Todd or Gina hears Fido barking (again). 6.3 6.4 Todd or Gina presses the button on the remote control. The door shuts automatically. Fido goes back inside. 8 7 The dog door opens (again). 6.5

  6. The new scenario Gina, open the dog door…Fido won’t quit barking! Woof! Woof! Todd or Gina hears Fido barking. 2 Todd or Gina presses the button on the remote control. Woof! Woof! 3 Fido barks to be let out. I feel much better now! 1 The door shuts automatically. 6.1 The bark recognizer “hears” a bark. 2.1 The dog door opens. 4 The bark recognizer sends a request to the door to open. 3.1 Fido goes outside. 6.3.1 5 The bark recognizer “hears” a bark (again). Fido barks to be let back inside. 6.2 Again with the barking! Someone let Fido back inside 6.4.1 The bark recognizer sends a request to the door to open. Fido does his business. 6 Todd or Gina hears Fido barking (again). 6.3 6.4 Todd or Gina presses the button on the remote control. Fido goes back inside. The door shuts automatically. 7 8 The dog door opens (again). 6.5

  7. We now have an alternate path Does this make sense to you? How would you improve it?

  8. An improved document

  9. A chain of development artifacts Requirements Documentation Design documents and classes Tests Code

  10. Review the old design Multiplicity Association

  11. Our new design

  12. The new BarkRecognizer class This is really simple, trivial actually. public class BarkRecognizer { private DogDoor door; public BarkRecognizer(DogDoor door) { this.door = door; } public void recognize(String bark) { System.out.println(" BarkRecognizer: Heard a '" + bark + "'"); door.open(); } }

  13. It’s really great that we applied the Information Expert. Why is it so great? Is there a principle here?

  14. If we hadn’t refactored … Just copy the code for closing the door automatically from the Remote to the BarkRecognizer. What do you think of Doug’s idea? This is Doug. He’s not a programmer.

  15. What’s wrong with Doug’s idea? 1 You might copy the code incorrectly 2 If you add another type of device you have to copy the code again 3 The more copies you have the more you have to change when requirements change 4 It’s just plain sloppy and ugly

  16. Speaking of ugly public class BarkRecognizer { private DogDoor door; public BarkRecognizer(DogDoor door) { this.door = door; } public void recognize(String bark) { System.out.println(" BarkRecognizer: Heard a '" + bark + "'"); door.open(); } } This is ugly code

  17. This is much better /** * This class represents the bark recognizer that opens the device it * controls if presented with a known bark. * * @author gpollice */ public class BarkRecognizer { private DogDoor door; /** * Constructor initializes this recognizer by storing the device it * controls and the bark it recognizes. * * @param door- door the recognizer controls */ public BarkRecognizer(DogDoor door) { this.door = door; } …

  18. Woof! (Which means: What’s the purpose of the Bark parameter in the BarkRecognizer?) • What is the Bark for? • Do we need it? • What should we do?

  19. Our second release is ready to go • We’ve gone through another iteration • Requirements • Design • Code • Test • We took on a manageable chunk of work • We delivered a working system

  20. Things to think about • Are the Remote and the BarkRecognizer similar? • Can you encapsulate the similarities? • How would this change the system? • We haven’t implemented a Bark class. How would you do that? • What do we gain from it?

  21. Time to refactor Modify the code. How is it better?

More Related