Object Oriented Design

 Objects have state  information to give to other objects  information to enable some actions  Objects have behavior  functionality, the ability to do things

1 A Project has many objects. Each can:

 send messages  receive messages  process data  Example -- a car  state: engine-running, 5gal fuel, ...  methods: startEngine, turnOnWiper...  turnUpRadio,...

2 Abstraction

 is a major feature of good design  Throw away all irrelevancy  Idealize and simplify what is important  This is not an absolute  different abstractions of “Car”  for normal drivers  for professional race drivers  for mechanics

3 Class

 Each Frame you’ve ever seen is likely different from other frames  Nevertheless  all Frames share some common features  A Class is a set of objects that share some common structure and share some common behaviors  serve as a blueprint for objects

4 UML and design tools

 UML -- Unified  notation and diagrams to help with OO design  Tools  Many GUI tools exist to help with the process  draw UML diagrams  convert to Java “shells”  www.uml.org 5 Some players

 Grady Booch  Chief Scientist “Rational ” (IBM)  Enthusiastic supporter of design patterns  co-developer of UML  Bertrand Meyer  developed Eiffel  “”

6 Designing Prisoner’s Dilemma

 Need lots of players  common features  image  name  strategy  differences ??  image  name 7  strategy My solution

 All players have the same getImage() and getName() method  But the actual value returned by these methods is established differently for each class of player  The Strategy is a different method for each class of player  so make it abstract

8 abstract class Player

 Each class extending Player specifies its own myImage and myName  But accessor methods common  Image getImage() { return myImage;}  String getName() { return myName;}  Profound differences between play methods -- hence:  abstract char play(char[] history) 9 Then each class that extends

 Player needs:  assign a value to myImage  assign a value to myName  provide a play(char[] history) method  class Porky extends Player  class Bugs extends Player  etc.

10 Is that the only design?

 Is it the best design?  Must we stick with that design?  ...

11 Displaying the tournament

 Each of n players  plays against each of n players  So there are n*n contests  An n*n grid seems an obvious approach  Discuss the design of BoardPanel

12 BoardPanel discussion

 Why (n+1)*(n+1)?  or even (n+1)*(n+2)?  Was this a good design decision?  shows signs of adapting a previously designed program without a re-design  Why do we need Square?  was this a good design decision?  better suggestion?

13 Hangman

 a familiar (?) game  I type in a word  then it’s hidden (replaced by -)  You guess one letter at a time  if you miss, one more piece of you is hung from the gallows  let’s design a gui

14 Drawing the victim

 need a drawing surface  so let’s extend java.awt.Canvas  extra state needed:  count the wrongGuesses : int  extra functionality needed:  addWrongGuess : public void()  note we’ll need a repaint()  why?  we always draw the scaffold 15 State and functionality

 HangmanCanvas will keep track of wrong guesses and the victim’s picture  But who will tell the HangmanCanvas what it needs to know?

16 Division of Responsibility

HangmanCanvas ???????? wrongGuesses: int

void addWrongGuess() void paint(Graphics g)

Graphics

17 How about a smart Textfield?

 Let’s go low-level again  State:  the word  what to display  Functionality:  receive a letter as a guess  reveal it if guess is correct  tell the HangmanCanvas if not

18 HangmanTextField

HangmanTextField toBeGuessed: String displayString: StringBufer void getGuess(char c) void reset()

19 Division of Responsibility

HangmanTextField HangmanCanvas wrongGuesses: int toBeGuessed: String displayString: StringBufer void addWrongGuess() void getGuess(char c) void paint(Graphics g) void reset()

Graphics

20 So who’s going to

 call getGuess() in HangmanTextField?

Hangman??? generate a char HangmanTextField

toBeGuessed: String displayString: StringBufer void getGuess(char c) void reset()

21 HangmanPanel

 display a keyboard  grap a char and send it to the HangmanTextField  Back to the exercises for the code

22 The whole thing

 We’ve abstracted  we solved three small problems  HangmanCanvas draws pictures in response to being told about wrong guesses  HangmanTextField  inputs the target phrase  receives guesses  updates the display if it’s a correct guess  tells the HangmanCanvas otherwise  HangmanPanel displays a grid of letters to be

guessed. Passes them to HangmanTextField23 The big picture

HangmanTextField Game Design by composition toBeGuessed: String Composes three objects displayString: StringBufer void getGuess(char c) void reset()

HangmanPanel

HangmanCanvas actionListeners on 26 buttons wrongGuesses: int actionPerformed() void addWrongGuess() void paint(Graphics g) 24 Abstraction and Decomposition

 are the key to success  Figure out what is essential  Figure out “bite-size” chunks of the problem  Put it all back together again

25 let me count the ways

 Is there one correct decomposition?  Is there one correct design?  Is there one correct abstraction?  Do the “experts” agree?  Why don’t I teach you a good design tool?  ...  26 More advantages

 to thoughtful decomposition  easy maintenance  easy modification  last exercise

27