Reading This Week CPSC 111, Intro to Computation Jan-Apr 2006 - PDF document

University of British Columbia Reading This Week CPSC 111, Intro to Computation Jan-Apr 2006 � Chap 3 (today) � Re-read Chapter 4.3-4.5 (Thursday) Tamara Munzner � reminder - code examples created in class posted by slides and assigned reading Class Design III Lecture 8, Tue Jan 31 2006 based on slides by Paul Carter http://www.cs.ubc.ca/~tmm/courses/cpsc111-06-spr News Exam � Midterm reminder: Tue Feb 7, 18:30 - 20:00 � Assignment 1 due today 5pm � Geography 100 & 200 � Wed office hours 11:30-12:30 not 11-12 � Exam conflict: email me today � reminder: in X661 � Windows home setup guide posted to � DRC: Disability Resource Center WebCT � academic accomodation for disabilities � forms due one week before exam (today!) � Reminders � http://students.ubc.ca/access/drc.cfm � CSLC is available if you need help � Check ugrad email account regularly (or forward to active account) � grade info sent there Correction: UML Recap: UML � UML diagram for Die class we designed � UML diagram representing class design Classname Die + field: type - sides: int fields fields - field: type + Classname() + Die() + method(): return type + setSides(numSides: int): methods void + method(param1 type, methods param2 type): return + roll(): int type - method(): return type

Objectives Recap: Separation and Modularity � understand how to design new classes using � Design possibilities abstraction and encapsulation � Die and RollDie as separate classes � understand how to implement new classes in � one single class that does it all Java � Separation allows code re-use through modularity � understand how to comment classes using � another software design principle javadoc conventions � One module for modeling a die: Die class � understand how to create documentation � Other modules can use die or dice using javadoc � we wrote one, the RollDice class � understand how to finish refining code � Modularization also occurs at file level � modules stored in different files � also makes re-use easier Recap: Control Flow Between Modules Key Topic Summary � So far, easy to understand control flow: order Borrowed phrasing from Steve Wolfman in which statements are executed � Generalizing from something concrete � march down line by line through file � fancy name: abstraction � Now consider control flow between modules � Hiding the guts from the outside Die class methods � fancy name: encapsulation Client code public int roll() int rollResult; � Keeping one part from stomping on another { myDie.setSides(); … � fancy name: modularity } rollResult = myDie.roll(); � Breaking down a problem public void setSides() � fancy name: functional decomposition { … } Implementing Point and PointTest Commenting Code � Conventions public class Point { � explain what classes and methods do � plus anywhere that you've done something nonobvious � often better to say why than what � not useful int wishes = 3; // set wishes to 3 � useful int wishes = 3; // follow fairy tale convention }

javadoc Comments javadoc Method Comment Example � Specific format for method and class header /** comments Sets the die shape, thus the range of values it can roll. @param numSides the number of sides of the die � running javadoc program will automatically generate */ HTML documentation public void setSides(int numSides) { � Rules sides = numSides; } � /** to start, first sentence used for method summary � @param tag for parameter name and explanation /** Gets the number of sides of the die. � @return tag for return value explanation @return the number of sides of the die � other tags: @author , @version */ � */ to end public int getSides() { return sides; � Running } % javadoc Die.java % javadoc *.java javadoc Class Comment Example Cleanup Pass /** Die: simulate rolling a die � Would we hand in our code as it stands? * @author: CPSC 111, Section 206, Spring 05-06 � good use of whitespace? * @version: Jan 31, 2006 � well commented? * * This is the final Die code. We started on Jan 24, � every class, method, parameter, return value * tested and improved in on Jan 26, and did a final � clear, descriptive variable naming conventions? * cleanup pass on Jan 31. � constants vs. variables or magic numbers? */ � fields initialized? � good structure? � follows specification? � ideal: do as you go � commenting first is a great idea! � acceptable: clean up before declaring victory Formal vs. Actual Parameters Scope � formal parameter: in declaration of class � Fields of class are have class scope: � actual parameter: passed in when method is accessible to any class member called � in Die and Point class implementation, fields accessed by all class methods � variable names may or may not match � Parameters of method and any variables � if parameter is primitive type declared within body of method have local � call by value: value of actual parameter copied scope: accessible only to that method into formal parameter when method is called � not to any other part of your code � changes made to formal parameter inside � In general, scope of a variable is block of method body will not be reflected in actual code within which it is declared parameter value outside of method � block of code is defined by braces { } � if parameter is object: covered later