Question of the Day

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?

2. Lecture 7:Public vs. Private

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 • 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

5. 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

6. 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

7. Params & Locals vs. Fields Local always best choice to hold data Use others only when needed

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 145did 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: privateintfieldName; • 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 getFieldorisFielddepending on type public fieldTypegetField(){ • 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 setFieldbut using actual name of field public void setField(fieldTypeparam){ • 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 publicor 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 1st 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 • Due Tuesday at 5PM(via Assignment Submitter) • During this lecture, we covered problem #1