1. Question of the Day  On a game show you’re given the choice of three doors: Behind one door is a car; behind the others, goats. After you pick a door, the host, opens another door which has a goat. He then asks, "Do you change your selection?” Should you?

3. Params & Locals vs. Fields  Locals “live” for method or block within method  Name may be reused, but no relationship exists  Parameters pass data between methods  But receiving method must be called by sender  Fields store data between calls or even longer  Values available with instance (or longer if static)  Local always best choice to hold data  Easiest choice; use others only when needed

4. Params & Locals vs. Fields

8. Packages  All classes reside in a package  Declared at start of class file: package pkgName;  Classes in default package if not specified  Package part of full name of class  Within a package, class names must be unique  Between packages can reuse class names  Some classes usable without full name  Cannot import classes in default package  These classes are nearly useless

9. Why Use Packages?  Simplify organization of classes  Each package has small set of related classes  Can nest packages (e.g., java.util )  Enables creating hierarchy of related classes  Limits knowledge needed by programmer  Java programs use 1000s of classes  How many of these do you know?

10. Real-Life Debugging Story  System crashed when field was null  145 assignments in 100,000+ LOC  1 out of 145 did not check for null  Took 2 weeks to find & fix bug  Remembered class & its field’s issues  Saved time figuring out bug  Ultimately, I got lucky to fix this  Preventing bug is clear goal

11. Visibility Modifiers  Specify usage of classes, methods, or fields  Each modifier has different purpose  private – Access within same class (file) only  protected – Use anywhere in package or subclass  public – Use at anywhere & at any time  “package” – Lazy developer did not type a modifier

12. Common Nightmare

13. Prevent the Nightmare  Everyone tries keeping certain details private  What is exposed is limited

14. Prevent the Nightmare  Everyone tries keeping certain details private  What is exposed is limited

15. Prevent the Nightmare  Everyone tries keeping certain details private  What is exposed is limited  Limit how & why changes occur

16. Prevent the Nightmare  Everyone tries keeping certain details private  What is exposed is limited  Limit how & why changes occur  Stop others from seeing changes

17. Prevent the Nightmare  Exact same holds for objects  Make fields private unless for very important reason: private int fieldName;  Limits errors since field accesses entirely in 1 file  Improves modularity of your program  Makes object-oriented programs easier to write

18. Accessor Methods  Gets field’s value in another class  Getter methods useful, but not special  Named get Field or is Field depending on type public fieldType get Field () {  Other classes must use accessor method  Easily limit access by adding check for password  Searching for field’s uses is also simple

19. Mutator Methods  Sets field’s value from code in another class  Like getters, just another method  Named set Field but using actual name of field public void set Field (fieldType param) {  All field changes normally via mutator  Updates can be checked to insure value is legal  Number of ways creating bugs is limited

20. Visibility of Methods  Methods normally act on or with object  Use active verb as name  Declare as either public or protected  Replace copies of code with single method  May have common test, calculation, &c.  Work is internal to how class performs tasks  These methods should be private  Simplifies coding & debugging this class

21. Access Protection Benefits  Enforce constraints on object's state  Amount of understanding required is limited  Private members hidden unless rewriting code  Provide simple client interface  Abstraction: Make available only what people must know  Encapsulation: Separate interface from implementation

22. Your Turn  Get into your groups and complete activity

23. For Next Lecture  Study for term’s 1 st quiz on Friday  Includes everything we have covered so far  Focus on types, fields, methods, objects, variables…  Problems like activities, weekly assignments, etc.  (Finish) Reading for tomorrow’s lab on web  Provides good explanation about what we are doing  Week #3 assignment on Angel for you to start 5PM  Due Tuesday at 5PM (via Assignment Submitter)  During this lecture, we covered problem #1