Code reading skills LEVEL GAME

 Common scenario:  Students raise hand. Point to code, say they don’t understand why it’s not working.  public void someFn() {  if (some condition)  do some action;  }  assumption: method is called  assumption: if condition is true  Test your assumptions! How? println OR use debugger  GUI program… println may be better  repeated code… println may be better  otherwise… debugger may be better DEBUGGING AS SCIENTIFIC METHOD

 Eclipse will take you directly to the line of code generating the error  obj.var OR obj.method()  What if: obj.method(obj2.getter().method());  May need to break apart to see which is null  In general, null pointer exceptions are fairly easy to diagnose. 1.Figure out which object is null 2.Figure out where you think memory should have been allocated 3.Figure out why it wasn’t (often because method that allocates space is not actually called, OR you allocate space for a local variable)  Remember, you need to allocate space for the collection (array, ArrayList, etc.) AND allocate space for each element in the collection. NULL POINTER EXCEPTION

UML

for (Moveable piece : movingPieces) { piece.move(pieces, playerLocation); } for (InteractingPiece piece : interactingPieces) { InteractionResult result = piece.interact(pieces, playerLocation); // use result to determine how to update player status } for (? piece : pieces) { if this piece moves move it…. NOTE: all pieces must now have a move method (may be blank) if this piece interacts get the result …. NOTE: all pieces must now have interact method update INTERFACES CAN SIMPLIFY CODE

 Don’t make your interfaces “fat”  no client should be forced to depend on methods it does not use.  ISP splits interfaces which are very large into smaller and more specific ones so that clients will only have to know about the methods that are of interest to them. INTERFACE SEGREGATION PRINCIPLE Wikipedia

 Single Responsibility Principle  every class should have responsibility over a single part of the functionality provided by the software, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility.  Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change.  Why would LevelEngine change? Ultimately, it would change if config files that define levels change.  Why would GameEngine change? If rules of game play change.  What if we don’t expect level definition format to change? May not need two classes. DO WE NEED LEVEL ENGINE?

WITHOUT LEVEL ENGINE

 Purpose of UML is to communicate  Agile manifesto: value working software over comprehensive documentation  Does NOT mean no documentation ever!  UML is used especially to show relationships between classes  Do we need all the GameEngine details?  In fact, do all the GameEngine methods need to be public?  Would any other class call these methods? UML COMPLEXITY

WITH PRIVATE METHODS

 Use abstract class if there are common attributes  Use abstract class if you want to provide some (but not all) method implementations  THIS EXERCISE  No attributes that are really needed for ALL pieces  BUT, it’s a simple enough game that a valid alternative might be to use an abstract Piece class  In a more complex game, might want to stick with interfaces  Enemy: weapon, strength, attack()  Friend: goodWill, assist()  Treasure: pointValue  Obstacle: secretWord, disable()  All can be drawn, some move and some don’t INTERFACE VS ABSTRACT CLASS

ABSTRACT CLASS