hfooad chapter 3 change: the constant in software development

21
HFOOAD Chapter 3 Change: the constant in software development

Upload: chrystal-small

Post on 29-Jan-2016

219 views

Category:

Documents


2 download

TRANSCRIPT

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

HFOOAD Chapter 3

Change: the constant in software development

Page 2: HFOOAD Chapter 3 Change: the constant in software development

2

And you’re responsible for changing your programs

Page 3: HFOOAD Chapter 3 Change: the constant in software development

Great dog door, but…

3

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.

Page 4: HFOOAD Chapter 3 Change: the constant in software development

What might change?

4

Hardware (new and modified)

The use case

The code (implementation and tests)

1

2

3

4

Page 5: HFOOAD Chapter 3 Change: the constant in software development

The old scenario

5

The dog door opens (again).6.5

Fido barks to be let out.1

Todd or Gina hears Fido barking.2

Todd or Gina presses the button on the remote control.

3The dog door opens.4

Fido goes outside.5

Fido does his business.6

The door shuts automatically.6.1

Fido barks to be let back inside.6.2

Todd or Gina hears Fido barking (again).

6.3

Todd or Gina presses the button on the remote control.Fido goes back inside.7The door shuts automatically.8

Woof! Woof!

Gina, open the dog door…Fido won’t quit barking!

I feel much better now!

Woof! Woof!

Again with the barking! Someone let Fido back inside

6.4

Page 6: HFOOAD Chapter 3 Change: the constant in software development

The new scenario

6

The dog door opens (again).6.5

Fido barks to be let out.1

Todd or Gina hears Fido barking.

2

Todd or Gina presses the button on the remote control.

3

The dog door opens.4

Fido goes outside.5

Fido does his business.6

The door shuts automatically.6.1

Fido barks to be let back inside.6.2

Todd or Gina hears Fido barking (again).

6.3

Todd or Gina presses the button on the remote control.

Fido goes back inside.7The door shuts automatically.8

6.4

The bark recognizer “hears” a bark (again).

6.3.1

The bark recognizer sends a request to the door to open.

6.4.1

The bark recognizer “hears” a bark.

2.1

The bark recognizer sends a request to the door to open.

3.1

Page 7: HFOOAD Chapter 3 Change: the constant in software development

We now have an alternate path

7

Does this make sense to you?How would you improve it?

Page 8: HFOOAD Chapter 3 Change: the constant in software development

An improved document

8

Page 9: HFOOAD Chapter 3 Change: the constant in software development

A chain of development artifacts

9

Requirements

Design documents and

classes

Code

Tests

Documentation

Page 10: HFOOAD Chapter 3 Change: the constant in software development

Review the old design

10

Association

Multiplicity

Page 11: HFOOAD Chapter 3 Change: the constant in software development

Our new design

11

Page 12: HFOOAD Chapter 3 Change: the constant in software development

The new BarkRecognizer class

12

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 really simple, trivial actually.

Page 13: HFOOAD Chapter 3 Change: the constant in software development

13

It’s really great that we applied the Information Expert.

Why is it so great?

Is there a principle here?

Page 14: HFOOAD Chapter 3 Change: the constant in software development

If we hadn’t refactored …

14

Just copy the code for closing the door automatically from the Remote to the BarkRecognizer.

This is Doug. He’s not a programmer.

Page 15: HFOOAD Chapter 3 Change: the constant in software development

What’s wrong with Doug’s idea?

15

You might copy the code incorrectly

If you add another type of device you have to copy the code again

It’s just plain sloppy and ugly

1

2

3

4

The more copies you have the more you have to change

when requirements change

Page 16: HFOOAD Chapter 3 Change: the constant in software development

Speaking of ugly

16

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

Gary Pollice
This is an image of Sam, the ugliest dog ever. I took it from http://www.samugliestdog.com/. There should be a drawing or something to replace it or I guess we need to get permission to use this.
Page 17: HFOOAD Chapter 3 Change: the constant in software development

This is much better

17

/** * 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;}

Page 18: HFOOAD Chapter 3 Change: the constant in software development

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?

Page 19: HFOOAD Chapter 3 Change: the constant in software development

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

19

Page 20: HFOOAD Chapter 3 Change: the constant in software development

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?

20

Page 21: HFOOAD Chapter 3 Change: the constant in software development

Time to refactor

21

Modify the code.How is it better?