1. University of British Columbia CPSC 111, Intro to Computation 2009W2: Jan-Apr 2010 Tamara Munzner 1 More Class Design Lecture 11, Fri Jan 29 2010 http://www.cs.ubc.ca/~tmm/courses/111-10 borrowing from slides by Paul Carter and Wolfgang Heidrich

2. 2 Reminders n Assignment 1 due Wed 5pm n TA office hours in DLC n http://www.cs.ubc.ca/ugrad/current/resources/cslearning.shtml n Check your ugrad email account regularly (or forward to active account) n grade info will be sent there

3. 3 Exam n Midterm reminder: Mon Feb 8, 18:30 - 20:00 n FSC 1005 n exam will be one hour, extra time is just in case needed n I'll discuss coverage next time n DRC: Disability Resource Center n academic accommodation for disabilities n forms due one week before exam (Monday!) n http://students.ubc.ca/access/drc.cfm http://students.ubc.ca/access/drc.cfm

4. 4 Recap: Public vs Private n public keyword indicates that something can be referenced from outside object n can be seen/used by client programmer n private keyword indicates that something cannot be referenced from outside object n cannot be seen/used by client programmer

5. 5 Recap: Designing Classes n Blueprint for constructing objects n build one blueprint n manufacture many instances from it n Consider two viewpoints n client programmer: want to use object in program n what public methods do you need n designer: creator of class n what private fields do you need to store data n what other private methods do you need

6. 6 Public vs. Private Example public class Die {... public int roll()... private void cheat(int nextRoll)... }

7. 7 Public vs. Private Example Die myDie = new Die(); int result = myDie.roll();// OK myDie.cheat(6); //not allowed!

8. 8 Unified Modeling Language n Unified Modeling Language (UML) provides us with mechanism for modeling design of software n critical to separate design from implementation (code) n benefits of good software design n easy to understand, easy to maintain, easy to implement n What if skip design phase and start implementing (coding)? n code difficult to understand, thus difficult to debug n We’ll use UML class diagrams represent design of our classes n Once the design is completed, could be implemented in many different programming languages n Java, C++, Python,...

9. 9 UML Visual Syntax n + for public, - for private n fields above, methods below Classname fields methods + field: type - method(): return type + Classname() + method(): return type + method(param1 type, param2 type): return type - field: type

10. 10 UML for Die n UML diagram for Die class we designed Die fields methods - sides: int + Die() + setSides(numSides: int): void + roll(): int

11. 11 Separation and Modularity n Design possibilities n Die and RollDice as separate classes n one single class that does it all n Separation allows code re-use through modularity n another software design principle n One module for modeling a die: Die class n Other modules can use die or dice n we wrote one, the RollDice class n Modularization also occurs at file level n modules stored in different files n also makes re-use easier

12. 12 Control Flow Between Modules n Last week was easy to understand control flow: order in which statements are executed n march down line by line through file n Now consider control flow between modules int rollResult; myDie.setSides(); rollResult = myDie.roll(); public int roll() { … } public void setSides() { … } Client code Die class methods

13. 13 Designing Point : UML n class to represent points in 2D space

14. 14 Implementing Point public class Point { }

15. 15 Formal vs. Actual Parameters n formal parameter: in declaration of class n actual parameter: passed in when method is called n variable names may or may not match n if parameter is primitive type n call by value: value of actual parameter copied into formal parameter when method is called n changes made to formal parameter inside method body will not be reflected in actual parameter value outside of method n if parameter is object: covered later

16. 16 Scope n Fields of class are have class scope: accessible to any class member n in Die and Point class implementation, fields accessed by all class methods n Parameters of method and any variables declared within body of method have local scope: accessible only to that method n not to any other part of your code n In general, scope of a variable is block of code within which it is declared n block of code is defined by braces { }

17. 17 Commenting Code n Conventions n explain what classes and methods do n plus anywhere that you've done something nonobvious n often better to say why than what n not useful int wishes = 3; // set wishes to 3 n useful int wishes = 3; // follow fairy tale convention

18. 18 javadoc Comments n Specific format for method and class header comments n running javadoc program will automatically generate HTML documentation n Rules n /** to start, first sentence used for method summary n @param tag for parameter name and explanation n @return tag for return value explanation n other tags: @author, @version n */ to end n Running % javadoc Die.java % javadoc *.java

19. 19 javadoc Method Comment Example /** Sets the die shape, thus the range of values it can roll. @param numSides the number of sides of the die */ public void setSides(int numSides) { sides = numSides; } /** Gets the number of sides of the die. @return the number of sides of the die */ public int getSides() { return sides; }

20. 20 javadoc Class Comment Example /** Die: simulate rolling a die * @author: CPSC 111, Section 206, Spring 05-06 * @version: Jan 31, 2006 * * This is the final Die code. We started on Jan 24, * tested and improved in on Jan 26, and did a final * cleanup pass on Jan 31. */

21. 21 Cleanup Pass n Would we hand in our code as it stands? n good use of whitespace? n well commented? n every class, method, parameter, return value n clear, descriptive variable naming conventions? n constants vs. variables or magic numbers? n fields initialized? n good structure? n follows specification? n ideal: do as you go n commenting first is a great idea! n acceptable: clean up before declaring victory

22. 22 Key Topic Summary Borrowed phrasing from Steve Wolfman n Generalizing from something concrete n fancy name: abstraction n Hiding the ugly guts from the outside n fancy name: encapsulation n Not letting one part ruin the other part n fancy name: modularity n Breaking down a problem n fancy name: functional decomposition

23. 23 Reading Assignment Next Week n Chap 4.3-4.5 re-read