ITEC120

lab04:
javadoc; making instances; calling methods

Today we'll work with a partner; before leaving, check off which of the problems below you were able to finish.

• Open the latest version of the PizzaServer.java

• Get the code into BlueJ (by pasting, or saving&re-opening the file). Look at how the comments have been formatted, for each method and named constant. Namely,

  • Each comment begins with one extra asterisk, /**…*/.
  • There is one short sentence, perhaps followed by some details.
  • For each parameter which the method takes, there is a line @param, followed by the parameter name, followed by a short description of what that parameter means.
  • For methods, there is a line @return, stating (the meaning of) what the method returns. Test cases follow this.
  • You can also have an @author tag, although usually this is only done for the entire class, at the top of the file.
  Now, in the upper-right corner of the BlueJ window, where it says implementation, click on that and instead view the interface.

  Note how the documentation is automatically produced by BlueJ, using these specially formatted “javadoc” comments. (This isn't unique to BlueJ; it is a standard tool used in Java, and this particular format is catching on to other languages as well.)
  For the rest of the semester, we will also use this format.

  What does implementation vs interface mean? Take a gander at the interface for the Math class. When using Math.floor(·) or Math.PI, do you get to see the implementation, ever? No. This web page specifying the interface is all you are allowed to see. Likewise, when other programmers are using your code, they might only see your documentation, and nothing else. Please make sure the interface (a) gives others the information they need so that they can do their job, and (b) does not mention details of how you implement or calculate some result, since you might change how you calculate an answer (like the tax of an item after the legislature passes new laws) but the interface shouldn't change (your function still calculates the tax, and that's all others need to know).

• Using BlueJ's pop-up menus: create two PizzaServer instances (creating them with new, and then (when BlueJ prompts you) giving them variable-names. Call the getSalary on each of them to confirm they make minimum wage, and then set one of their salaries to something different. Confirm that the salary of that PizzaServer changes, while the other salary is unchanged.
• Do the same thing, but don't use any pop-up menus: Just by typing in BlueJ's Code Pane (as we saw in lecture), type new PizzaServer() to create new instances, and assign them to variable names just like any other local variable. (No need to have anything on the bench at all.)
• What is a java expression which corresponds to the sum of the salaries of the two PizzaServers you created above? Type it in, in the code pane.
• Let's take the java code you used in the last two steps, and instead of just typing it in the code pane and being done, let's put it inside a new function:
  
  • Create a function twoServersPoolMoney which takes no inputs, it creates two new PizzaServers, sets the salary of one of the servers to (say) $11/hr, and then calculates and returns the sum of their salaries. (There is only one possible test case -- calling the function with no inputs.) Use javadoc-style comments.
  • Adjust the previous function so that it takes in a number, and uses that number as the new salary for one of the servers. (Two test cases will suffice.) Use javadoc-style comments.
• Add a new behavior to PizzaServers:

  /** * Give a textual description of this PizzaServer. The text will * mention that that it describes a PizzaServer, and will include * the value of its field(s). * * @return A string representation of this PizzaServer. * A sample return value might be "[PizzaServer -- salary: $4.23]" * but with the salary field reported appropriately. */ String asString() { return "...replace me..."; /* Note: If we ever add more fields to this class, * we should come back and update asString to print those out too. */ }

  You cannot ask the object to include the name of the variable by which the caller is referring to them (e.g. “ps2”), because the PizzaServer doesn't know what variable asString's caller uses to refer to it; that's not in the PizzaServer's scope.)
  NOTE: There is something a bit fishy here, when somebody will later call (say) ps2.asString() -- that is, when they say “Hey ps2, give me a String description of yourself”. ps2 wants to call their own method getSalary, in this function. This code works, BUT -- unlike what we were talking about before, you didn't write a PizzaServer-reference, followed by dot, followed by getSalary. There is definitely something being done for us, behind the scenes, which allow this to work without that dot bit!
• Write a function called constructSalariedServer, which takes in a number sal, and it returns a (new) PizzaServer whose salary is sal. Use javadoc-style comments.
• [Challenge, if you have time] Write a method PizzaServer makeClone( PizzaServer original ) which takes in a PizzaServer and returns a new PizzaServer which looks identical to the one passed in the object whose makeClone method you called. (That is, you walk up to a PizzaServer, and say “give me a clone of yourself”---which is more than just asking for their salary, but conceptually similar.).

  PizzaServer jo = new PizzaServer(); jo.setSalary( 12.34 ); PizzaServer moe = jo.makeClone(); moe.getSalary() /* Should be 12.34. */

  
  How can somebody calling your function test whether the clone and the original really are two different PizzaServers, and not the exact identical same PizzaServer, using only the topics covered in class so far?

©2006, Ian Barland, Radford University Last modified 2006.Sep.20 (Wed)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu