Methods - Learning Station

Station 1: Constructing Code

AS A GROUP, construct the code to match the description provided in the Javadoc Comments Don’t split up the work! Do it together! What strategy did you use to help you construct the code? What are some important tips for avoiding syntax errors when defining methods. Add any additional reflections on what you learned in this station.

Like in previous constructing learning stations, I worked top down. I knew that I was supposed to create a method, so I looked for the access modifier and then the class modifier. Since there were only so many options that I learned for these values, it was easy to find them. Next I looked for the method return data type. Depending on what the return in the Javadoc was, I could determine what I’d need to put. The method name was actually one of the harder parts to find since it wasn’t stated anywhere so I didn’t know the exact code block. Once, I found that, it was time to move onto the parameters. The Javadoc stated the parameters and what they did, so I was able to find them and insert them into the brackets. With the method header done, I was then able to move onto the rest of the code. I looked for any variables I need to declare and then and calculations that I needed to do. The return line could be done easily as well since I knew what it should be according to the Javadoc. The last slide contained a for loop, since I knew the format of a for loop, I was able to find the code blocks that made it. It helped having the methods lesson on the side as a reference. I think working in order also helped with avoiding syntax errors. I knew that I would need a certain code block at a certain point.

Station 2: Missing pieces

AS A GROUP, write the missing pieces of code for the METHOD HEADER (just the method definition - no code inside the method) for the given METHOD CALL. Use a, b, c as your parameter variables as needed. Compared to Python, how are Method Headers different in Java? Add any additional reflections on what you learned in this station.

def aloe(brand):
  """
  This function gives
  nutrional facts of
  aloe based on brand
  """

Above is an example of what a method header would look like in Python. When defining a method, you need to use the keyword “def”. You would then put the name of the method followed by any parameters that would be passed through in brackets. It would need to have a colon after the brackets. The docstring would usually be placed under the function. The Python way of method headers looks easier than Java. In Java, you need to have the access modifier, class method, and method return data type. The method name and method parameters are similar between the two languages, except that you always need to declare the variable in Java (double a, String b). Java also uses curly brackets for everything in the method while Python uses a colon and tab spacing. The final thing is that the placement of the docstrings are different. I’ve seen the docstrings placed above the method headers in Java while in Python I’ve seen them placed below. The method headers looked very complicated at first, but when spread out to its components, it doesn’t seem as complicated.

Station 3: Trace Tables

1. INDIVIDUALLY, predict the output by dragging the green circle to the correct answer
2. AS A GROUP, compare your results with each other and discuss any values that do not match in the tables

What gave you the most trouble? What helped you solve it? Add any additional reflections on what you learned in this station.

The third slide and the sixth slide both gave me quite a bit of trouble. I didn’t notice the output inside one of the methods as I thought the code would’ve been very close to the previous slide. It helped having a partner as they got a different answer, so when I checked my answer again, I was able to see my mistake. The sixth slide was a bit confusing since there were quite a few plus signs. It helped remembering that the placement of the signs mattered and having a partner to double check with. This station showed me that I shouldn’t take some parts of code for granted. Even when the code looks simple at a glance, it is best to look at it thoroughly to ensure that I’m not missing anything. Working together with a partner, like last time, was helpful in comparing answers as they could see mistakes that I overlooked.