|
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
Review: we can write a method swapAge (which modifies fields), but we can't write a method swapDogs (which modifies local variables).
Consider the class Die from lab08b—printing: Pair O' Dice. It has a method void roll(), which chooses a random number in 1..6, and sets the current face to be that. In turn, the method setFace actually does that. There is a difference between these two methods though: one we intend for other people to use, and the other is for internal use, and it would be cheating for other people to call it!
Die myd6 = new Die(); myd6.roll(); myd6.getFace() myd6.setFace(93); // Setter will make sure this is at least sane (if not fair) |
myd6.face = 93; // Cheating, from the Code Pad! |
class Die { int NUM_SIDES = 6; private int face = NUM_SIDES; //... } |
Similarly, the Date methods isInLeapYear() and isValid() are arguably for internal-use-only (users of the class might reasonable expect that they only ever see valid Date objects, and yet still inside the class we need to do internal checks for validity; in turn isInLeapYear() was just a helper function for isValid()).
We can make these assumptions clear: every field and method can be labeled with an adjective public or private:
A public method (or field) can be called by any other class.
In our example, Die's method roll should be public, because our whole purpose is to let people roll the die. getFace also needs to be public. What other methods should be public?
In PizzaServer, work and tip would all be public. On the other hand, spend and addToBalance probably aren't public -- those are actions which the PizzaServer might choose to do itself, but can't be initiated by EmCees or Dogs.
In particular, constructors are usually public!
A private method (or field) can only be called from within that same class (the same file).
That is, if PizzaServer's getBalance() is private, then that method can only be called by PizzaServers. A PizzaServer can call its own getBalance() (which it needs to do from inside addToBalance(), which might be public). This is perfectly reasonable.
In addition, a PizzaServer can also call getBalance on any other PizzaServer that it happens knows about. (For example, the following fragment works just fine:
public class PizzaServer { // comment omitted... private getSalary() { /* body omitted */ } // comment omitted... private hasHigherSalary( PizzaServer other ) { // It's legal for one PizzaServer to call another's private method. return (this.getSalary() > other.getSalary()); } } |
What this means for us: From now on, every method and field should be declared either public or private.
… while most of the methods will be public (since most methods we write are ones whose behavior we want others to use).
Only methods which are helpers to the primary methods (like setFace) will be private.
Rule of thumb: If you modify an object's internal implementation, you should not need to change any of the public signatures.For example, if we modify Date to have only one field int daysSince1900, others will still call getMonth just the same as before. But if they'd been calling accessing the month field directly, suddenly this our internal modification would break their code, oops! The problem is that really, they should not have been calling getHours anyway. By making that getter private, we ensure that nobody else could be calling it.
(Only code which dealt with non-public methods should have to worry about the new implementation.)
In fact, you might wonder if there is some “very-private” modifier which means “The method/field can only be accessed by this object itself”. Java does not have such a concept.
While such a protection-level is a very common design goal, and it makes sense from a pure object-oriented mindset, Java's philosophy is that if a programmer wants to violate privacy expecatations between PizzaServer, and that programmer has access to the source code for class PizzaServer, then that programmer could always do so: they'd just change the modifier from “very-private” to merely private.
If you ever design your own language though, it's worth not taking this for granted. Many features in programs are there to help protect programmers from themselves. (Declaring types in advance is one such feature.)
↩home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
©2008, Ian Barland, Radford University Last modified 2008.Mar.17 (Mon) |
Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu |