| ITEC 120 |
| 2008spring |
| ibarland, jdymacek |
|
|
|
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
We have seen that an object can
take in an objects as a parameter:
In lecture we wrote a
method for PizzaServers,
namely
We can also write methods where we return an objects1. For example, let's write a function for a PizzaServer which takes in two possible work-Dates, and decides which one they prefer. For example, given the choice of working 2007.Feb.21 and 2007.Feb.28, a particular PizzaServer might have a preference for 2007.Feb.21.
Let's write this method together, using the steps of The Design Recipe.
In addition to solving this particular problem about choosing a shift,
what we're really trying to teach is the recipe.
The same recipe guides you through all problems, even those which are
much more complicated than the one we work on here.
See the lect07b-soln.html,
for how each step corresponds to our problem at hand.
This function involves only two types of information: Dates, and PizzaServers. We have already developed classes to represent each of those, so we're done.
However, if we were starting a problem from scratch, this is an interesting and essential step, to decide what what information will be represented with primitive types, and what information will use an entire class.)
First: which class, does this method belong in -- is it a question we'll ask of PizzaServers, or of Dates? This is a question we ask PizzaServers, so it will be a method (behavior) of that class.
What are the inputs types? (How many inputs?) What is the type of answer which will be given?
Date whichDayToWork( Date d1, Date d2 ) |
/** Which Date does this PizzaServer prefer for their next shift,
* given a choice of two upcoming Dates.
* @param d1 The first date to consider working on.
* @param d2 The second date to consider working on.
* @return which Date is preferred for this PizzaServer's next shift.
* It will be one of d1,d2.
*/
|
Date whichDayToWork( Date d1, Date d2 ) {
return d1; // stub
}
|
We tell BlueJ to make a new test case2 The test suite included Date variables named today (that is, 2007.Feb.20, if you inspect the object), nextMonday (that is, 2007.Feb.26), nextFriday (that is, 2007.Mar.03), and moonLanding (that is, 1969.Jul.20). (Note how using descriptive variable names, back when we created the examples-of-the-data, has come in handy now. If we'd just named them all “date1”, “date2”, … it we be harder to use them now.
We start by asking one of the two (brand-new) PizzaServers if they'd prefer to work (say) nextMonday or nextFriday. But what will the correct answer be? Note how this is the first moment where we actually start thinking closely about the correct answer!
Sometimes, correctness is clear from context. If it's ever unclear, go back and ask your boss, or whoever had you write this program! In this case, where you might be writing SimPizzaServer&tm; your boss replies:
After a thorough review of the Journals of PizzaServer Psychology, it has been determined that:
If a PizzaServer has a balance of less than $100, then they prefer to work sooner, given two options. Otherwise, they prefer the later date.
Thus: pizzaSer1's balance is currently $0.00, so pizzaSer1.whichDayToWork( nextMonday, nextFriday ) should return nextMonday as the correct answer. Go ahead and assert this, using BlueJ's as one of our tests. (Note how we can use variables like “nextMonday” as inputs, and to compare against outputs.)
Another test case to ask: pizzaSer1.whichDayToWork( nextFriday, nextMonday ). Clearly this should give the same answer as before; we want to make sure our method (once it's working) isn't sensitive to which order its inputs come in on.
What are some degenerate inputs to try? Is there a "0" value, for a Date? Not really, but what bout Dates which aren't valid? Dates in the past? Hmm, either of these would make the question absurd; we expect our inputs to be valid dates which are still in the future. It's fine to presume that3, but say so! Thinking about degenerate inputs makes us realize we need to modify our javadoc:
* @param d1 The first date to consider working on. Must be a valid date, not in the past. * @param d2 The second date to consider working on. Must be a valid date, not in the past. |
Here are four tests, all of which are stressing a slightly different aspect of the problem:
assertEquals(nextMonday, pizzaSer2.whichDayToWork(nextMonday, nextFriday)); assertEquals(nextMonday, pizzaSer2.whichDayToWork(nextFriday, nextMonday)); assertEquals(nextMonday, pizzaSer2.whichDayToWork(nextMonday, nextMonday)); |
Yep, we need to consider PizzaServers who have money in the bank.
pizzaSer2.work(50); assertEquals(nextFriday, pizzaSer2.whichDayToWork(nextMonday, nextFriday)); assertEquals(nextFriday, pizzaSer2.whichDayToWork(nextFriday, nextMonday)); assertEquals(nextMonday, pizzaSer2.whichDayToWork(nextMonday, nextMonday)); |
The body of the function. This is the only non-automatic part of the process. Reflect on the test cases you worked through by hand: how did you get from the input to the output? What is the general case?
Things to help you on your way:
Date whichDayToWork( Date d1, Date d2 ) {
// ... d1 ... d2 ... this ...
return d1; // stub
}
|
For the Dates d1 and d2, we scan the documentation for our class. Hmm... the method sameDateAs won't help us with the problem. And we decided only to consider valid inputs, so we won't need to ask d1.isValid() or d2.isValid for this problem. getYear? Maybe. But when we see comesBefore, we realize that that's all the information we'll need to know about the dates: whether or not d1.comesBefore(d2). We have a winner!
What about this -- what is its type? It's a PizzaServer, of course. (We are kinda thinking of ourselves as the PizzaServer who was asked the question, and so this is a variable which refers to ourselves.) So, what questions can we ask the PizzaServer this? Clearly pizzaArea doesn't pertain to this problem, nor getSalary. But, we realize that getBalance is critical to this the answer we'll give.
Thus for our method, we have so far:
Date whichDayToWork( Date d1, Date d2 ) {
// ... d1.comesBefore(d2) ... this.getBalance() ...
return d1; // stub.
}
|
Often, the body of the function is just a return statement, although you might also name partial results using local variables, and use an if statement which contains a return statement or names partial results.
Clearly, we want to use an if to determine what to return, because our answer is entirely dependent on whether or not we have $100 or more in the bank:
Date whichDayToWork( Date d1, Date d2 ) {
if (this.getBalance() < 100) {
// ... d1.comesBefore(d2) ...
}
else { /* balance >= 100 */
// ... d1.comesBefore(d2)...
}
}
|
Okay, let's tackle each of the two cases separately.
if (d1.comesBefore(d2)) {
return d1;
}
else {
return d2;
}
|
Date whichDayToWork( Date d1, Date d2 ) {
if (this.getBalance() < 100) {
if (d1.comesBefore(d2)) {
return d1;
}
else {
return d2;
}
}
else { /* balance >= 100 */
// ... d1.comesBefore(d2)...
}
}
|
if (d1.comesBefore(d2)) {
return d2;
}
else {
return d1;
}
|
Date whichDayToWork( Date d1, Date d2 ) {
if (this.getBalance() < 100) {
if (d1.comesBefore(d2)) {
return d1;
}
else {
return d2;
}
}
else { /* balance >= 100 */
if (d1.comesBefore(d2)) {
return d2;
}
else {
return d1;
}
}
}
|
solution: PizzaServer.java, or the complete project (.jar). (See how to get .jar files into BlueJ.)
100 is a “magic number”. (See below)
Write a method nextDay. Use the recipe above. Note that steps I and II are already done; those steps apply to classes, and don't need to be repeated for further methods of a class.
First get a method working which may occasionally return an invalid date, but otherwise is correct.
Then, get a method which
handles the difficult cases.
Hint:
Make the obvious candidate, and see if it's valid.
If not, then make a second candidate, and check if that's valid.
If not, then a third try should do the trick.
This will be
Java's if-else is a statement -- it is on its own line(s), and it will happen before or after other statements, but it can't be combined as a sub-part of larger statements. This is different than expressions, like “Math.sqrt(16)” or “(a && b)”, which might occur as sub-expressions of the larger expression “(Math.sqrt(16) > x) || (a && b))”.
It turns out, there is a statement form of if-else, using the punctuation “?” and “:”.
conditonal-operator ::= condition ? expressiontrue : expressionfalseFor example, if a Dates have a predicate isLeapYear, and d is an instance of Date, then the following expression evaluates to the number of days in February:
d.isLeapYear() ? 29 : 28 |
d.getDay() <= (d.isLeapYear() ? 29 : 28) |
// ...inside isValid:
else if (this.getMonth()==2) {
return this.getDay() <= (this.isLeapYear() ? 29 : 28)
}
else // ... consider other months besides February
|
Note that the conditional operator must contain answer-expressions for both condition-being-true and condition-being-false. (This is different from if, which can legally be written without an else.)
We can use the conditional operator to make the above code more concise:
Date whichDayToWork( Date d1, Date d2 ) {
if (this.getBalance() < 100) {
return (d1.comesBefore(d2)) ? d1 : d2;
}
else { /* balance >= 100 */
return (d1.comesBefore(d2)) ? d2 : d1;
}
}
|
Challenge exercise: re-write the above statement starting with the decision of which date comes first, and (in each case) asking about what the balance is:
Date whichDayToWork( Date d1, Date d2 ) {
if (d1.comesBefore(d2)) {
return ? : ;
}
else { /* d1 doesn't come before d2 */
return ? : ;
}
}
|
Although most Java programmers tend to use if most of the time, the conditional expression is actually extremely handy, and you are encouraged to use it if you're comfortable with it.
1 Okay yes, the Constructor is already a method which returns an object, although we didn't actually write the return statement ourself. ↩
2Right-click on the test class, to find the Create Test Method... option. ↩
3Depending on whether your function will be called by other programmers or by end-users, and depending on how paranoid you are, you may want to actually check for these things. (See java's assert statement.) Ideally, just as we use type-declarations to help catch errors earlier (at compile time) it'd be nice to be able to specify the input type “valid, non-past Dates”, and have Java check for that automatically. (There are limits to trying to confirm this at compile time, but even so I'd like Java to automatically catch this error at run time and correctly blame the calling function. Type checking and run-time asserts are two partial solutions; it would be nicer if a language could even do more (even in the presence of inheritance).) ↩
4Well, we could call (new java.util.Date()), but that doesn't really affect our testing. ↩
5It would also be a great method to make static, if we'd learned about that yet. You see, the notion of the miminum is symmetric, and yet our code is asymmetric: we choose one of those two Dates to walk up to, and we pass it the other Date as a parameter. Really, like min, we'd like to just walk up to the Date class (the blueprint), and hand it two Dates, and have it decide which one comes sooner. It's an aesthetic offense, to have an asymmetric method computing a symmetric function. ↩
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
| ©2008, Ian Barland, Radford University Last modified 2008.Feb.27 (Wed) |
Please mail any suggestions (incl. typos, broken links) to iba�rland  rad�ford.edu |
 |