HFOOAD Chapter 3 Change: the constant in software development.

Slides:



Advertisements
Similar presentations
Chapter 7 Constructors and Other Tools. Copyright © 2006 Pearson Addison-Wesley. All rights reserved. 7-2 Learning Objectives Constructors Definitions.
Advertisements

Observer Method 1. References Gamma Erich, Helm Richard, “Design Patterns: Elements of Reusable Object- Oriented Software” 2.
ATM User Interface Design. Requirements A bank customer is able to access his or her account using an automatic teller machine. To be able to use an ATM.
Fall 2007CSE 115/503 Introduction to Computer Science for Majors I1 Association relationship We’ve seen one implementation of “knows a”: public class Dog.
H OW O BJECTS B EHAVE. O VERVIEW Methods use object state Arguments and return types in methods Java passes by value Getters and Setters Encapsulation.
Chapter 5 Part 1 COSI 11a Prepared by Ross Shaull.
CS 106 Introduction to Computer Science I 11 / 15 / 2006 Instructor: Michael Eckmann.
Lesson 3 Variables – How our Brains Work - Variables in Python.
Starting Chapter 4 Starting. 1 Course Outline* Covered in first half until Dr. Li takes over. JAVA and OO: Review what is Object Oriented Programming.
Multiple Choice Solutions True/False a c b e d   T F.
1 Design and Integration: Part 1 Nuggets about Design vs Project Management.
Lecture 18 Page 1 CS 111 Online Design Principles for Secure Systems Economy Complete mediation Open design Separation of privileges Least privilege Least.
CS 350 – Software Design The Object Paradigm – Chapter 1 If you were tasked to write code to access a description of shapes that were stored in a database.
Applied Software Project Management Andrew Stellman & Jennifer Greene Applied Software Project Management Applied Software.
Programming in Java Unit 2. Class and variable declaration A class is best thought of as a template from which objects are created. You can create many.
Week 4 Introduction to Computer Science and Object-Oriented Programming COMP 111 George Basham.
HFOOAD Chapter 2 Requirements. We create software for a reason. We create software fro people. We need to know what the people want in the software we.
Object Oriented Analysis and Design Chapter 4: Analysis.
Question of the Day  On a game show you’re given the choice of three doors: Behind one door is a car; behind the others, goats. After you pick a door,
2. GATHERING REQUIREMENTS Object-Oriented Analysis and Design NTPCUG.
Agenda Object Oriented Programming Reading: Chapter 14.
ADTs and C++ Classes Classes and Members Constructors The header file and the implementation file Classes and Parameters Operator Overloading.
Week 4 Introduction to Computer Science and Object-Oriented Programming COMP 111 George Basham.
Requirements Change! Chapter 3 Object-Oriented Analysis and Design Tom Perkins.
1 Design and Integration: Part 2. 2 Plus Delta Feedback Reading and lecture repeat Ambiguous questions on quizzes Attendance quizzes Boring white lecture.
Topic 1 Object Oriented Programming. 1-2 Objectives To review the concepts and terminology of object-oriented programming To discuss some features of.
Chapter 4 Introduction to Classes, Objects, Methods and strings
Chapter 8 Inheritance Part 1. © 2004 Pearson Addison-Wesley. All rights reserved8-2 Inheritance Inheritance is a fundamental object-oriented design technique.
Programming with Java © 2002 The McGraw-Hill Companies, Inc. All rights reserved. 1 McGraw-Hill/Irwin Chapter 5 Creating Classes.
COP INTERMEDIATE JAVA Designing Classes. Class Template or blueprint for creating objects. Their definition includes the list of properties (fields)
CS 151: Object-Oriented Design August 29 Class Meeting Department of Computer Science San Jose State University Spring 2012 Instructor: Ron Mak
By Joaquin Vila Prepared by Sally Scott ACS 168 Problem Solving Using the Computer Week 13 More on Classes Chapter 8 Week 13 More on Classes Chapter 8.
The Strategy Design Pattern © Allan C. Milne v
CHAPTER 14 Classes, Objects, and Games XNA Game Studio 4.0.
GOOGLE GROUPS TRAINING How to use the internet to make the Own It! project teams as efficient and successful as possible.
 Write a description (or use one provided)  Create an initial encapsulation  Refine the encapsulation  Identify helpful constructors  Think about.
Chapter 2 lesson 5 Reaching Your goals. vocab Success- achievement of your goal Action plan- map that outlines the steps for reaching your goal Setback-
Engineering Classes. Objectives At the conclusion of this lesson, students should be able to: Explain why it is important to correctly manage dynamically.
In this class, we will cover: Overriding a method Overloading a method Constructors Mutator and accessor methods The import statement and using prewritten.
Constructors A constructor is a method that has the same name as the class itself It is automatically called when an object is instantiated (in other words,
Java: Variables and Methods By Joshua Li Created for the allAboutJavaClasses wikispace.
Outline Anatomy of a Class Encapsulation Anatomy of a Method Graphical Objects Graphical User Interfaces Buttons and Text Fields Copyright © 2012 Pearson.
Chapter 6 Functions The Tic-Tac-Toe Game. Chapter Content In this chapter you will learn to do the following: 0 Write your own functions 0 Accept values.
Class Definitions: The Fundamentals Chapter 6 3/30/15 & 4/2/15 Imagine! Java: Programming Concepts in Context by Frank M. Carrano, (c) Pearson Education.
3-July-2002cse142-D2-Methods © 2002 University of Washington1 Methods CSE 142, Summer 2002 Computer Programming 1
Copyright © 2002 Pearson Education, Inc. Slide 1.
Copyright © 2002 Pearson Education, Inc. Slide 1.
Memory Management.
Chapter 6 – Use Case Diagrams
More Sophisticated Behavior
Module Road Map Refactoring Why Refactoring? Examples
BIM Gatherıng Requırements Give Them What They Want
Review What is an object? What is a class?
The Object-Oriented Thought Process Chapter 06
Programming Design Patterns
Interfaces.
The Object-Oriented Thought Process Chapter 05
slides created by Ethan Apter
Encapsulation and Constructors
Anatomy of a Method.
CS 350 – Software Design A Standard Object-Oriented Solution – Chapter 4 Before studying design patterns, many programmers solve a problem by starting.
Constructors and Other Tools
slides created by Ethan Apter
Java Programming Language
Do you trust the 8 Ball? The 8 Ball always knows..
Prepared by :Adeel Ahmad
slides created by Ethan Apter and Marty Stepp
GST Implementation in Miracle
HFOOAD Chapter 5 Interlude
Introduction to Computer Science and Object-Oriented Programming
Presentation transcript:

HFOOAD Chapter 3 Change: the constant in software development

2 And you’re responsible for changing your programs

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.

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

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. 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. 7 The door shuts automatically. 8 Woof! Gina, open the dog door…Fido won’t quit barking! I feel much better now! Woof! Again with the barking! Someone let Fido back inside 6.4

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. 7 The door shuts automatically. 8 Woof! Gina, open the dog door…Fido won’t quit barking! I feel much better now! Woof! Again with the barking! Someone let Fido back inside 6.4 The bark recognizer “hears” a bark (again) The bark recognizer sends a request to the door to open The bark recognizer “hears” a bark. 2.1 The bark recognizer sends a request to the door to open. 3.1

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

An improved document 8

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

Review the old design 10 Association Multiplicity

Our new design 11

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.

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

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.

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 The more copies you have the more you have to change when requirements change

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

This is much better 17 /** * This class represents the bark recognizer that opens the device it * controls if presented with a known bark. * gpollice */ public class BarkRecognizer { private DogDoor door; /** * Constructor initializes this recognizer by storing the device it * controls and the bark it recognizes. * 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?

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

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

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