Object Oriented Design

Goals Review of Space Invader Projects Quick Outlook of rest of semester

Exciting One video game / week

Programming hints Careful with Wait as it will block all agents Also bad for keyboard responsiveness since waits add up and may keep agent from getting keyboard event => use OnceEvery

Project Submission Reminder We need projects NOT applets

This and that Please include a complete worksheet that is in an initial and complete state Output of attributes to user: use “say” action; show message does not support attribute substitution “you have ~lives lives left” => you have 5 lives left

Class Diagrams Naming of class Do not use plural to reflect the fact that there will be multiple instances “Aliens” => “Alien” Use descriptive, non-abbreviated terms “ScrCtr” => “Score Counter”

Sequence diagrams 1 Message needs to match operation of receiver NOT sender! If scenario does not include destroying the instance do not end the life line with “X” Diagram needs to have clear description of what situation/scenario is. Stick with one very specific execution path Do not try to mix different, independent situations

Sequence diagrams 2 Time is monotonically increasing: no arrows going UP! An arrow up implies negative time Arrows need to be horizontal. Otherwise they imply “non-instantaneous” messages Confusing activation with creating new instance :Invader :Invader :Bomb  new :Bomb new

Invader drops final bomb resulting in destroyed bunker Use iconic representations :Invader :Bunker Invader drops a bomb. [once ever 5 seconds] :Bomb new Bomb drops down and… [empty below] drop [empty below] drop … [empty below] drop [see a bunker below] hits a bunker. hit X erode Bunker erodes and disappears X

State diagrams State of WHAT? Individual object Set of objects Entire application user

What are states States describe situations, NOT processes nor functions Typically Use adjectives: blue, ready, busy, … Don’t use verbs: move, hit, … Don’t use verb/noun combinations: move bomb Use visual states where possible intact

Bunker states intact hit hit hit / erase(self) slightly damaged heavily damaged hit / erase(self)

Design and implementation Most of you did Bottom Up implement first, then design (UML) Classical school approach Top down: Design/UML first then implementation Reality Bottom up, top down, repeat XP (Extreme Programming)

Rest of the semester XP: Extreme Programming The Object Draw Editor design case OpenGL: 500 functions in one class Anti Patterns OOD meets AI: Game X Objects need Interfaces, Tamara Sumner Objecting to Objects, Wenming Ye Using Components for Rapid Distributed Software Development, Chris DiGiano