OOP - Learning Station

Station 1: Constructing Code

1. AS A GROUP, construct the code to match the UML
2. AS A GROUP, construct the code for the main method that instantiates the Fraction class and uses some of its instance methods

Don’t split up the work! Do it together! What strategy did you use to help you construct the code? What are some general tips you would add for defining objects?

The strategy that I used to help me construct the code was that I worked top down. Like with previous learning stations, I find that starting from the top and finding the necessary code makes things much easier. I knew that class and the variables were usually at the top of the code. I found the constructors a to be a bit more difficult as I didn’t think they set their values with mutators. I combined as much as I was confident in and moved on with the rest of the code. Once I was almost done the code, I could see that what remained and try to fit it into the code. This learning station helped me realize that you could call mutators in the constructors which would remove redundant code.

The FractionTest class wasn’t that bad as I could reference the code I did in the previous slide. I knew that there were certain formats when creating objects, so that also sped up the progress.

A tip for defining an object would be that look at all your variables from the UML and see which ones need to be set. If no values are passed through as a parameter, what are the default values? This way, it’ll be harder to miss setting variables that are needed in the object.

Another tip would be to copy and paste carefully, if the constructors are similar it might save time to copy the first one and add to it. However, you should look over both constructors to make sure that it is still fulfilling its purpose and that a mistake from the original hasn’t moved over to the other.

When creating an object, often you see the constructor name twice, once before the equal sign and once after. An example of this would be in the FractionTest class. This isn’t always the case, but it could prove helpful when creating multiple objects.

Station 2: Draw the UML

AS A GROUP, draw up the UML for the Java code on the left for each slide. Why do you think we use UML? Add any additional reflections.

I think we use UML because it helps plan out the program. The UML is much shorter compared to the code that it represents. It’s much easier to see what is part of the class at a quick glance. The UML can provide tons of information such as if something is private or a variable is constant. You can also see what parameters are needed and what is returned. Even after the code is done, the UML may prove useful. Another programmer could look at the UML and begin to understand the use of the class. If they are looking for a specific feature, it is much easier to find it in the UML first than to go through all of the code.

I think that using UML is very important when writing code as it can provide a good summary of what the class does and has. I could look at the current features and notice if something was missing. It would be very easy to plan a new feature and the requirements needed (parameters and returns). UML would also prove useful when I look back at my code and need to modify anything. This includes others who want to examine my code. Overall, UML is a very useful tool, it seems similar to inline and JavaDoc comments as all three help explain code.

Station 3: Predict the Code

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

Don’t split up the work! Do it together! What gave you some difficulty? Or, what do you think others would find difficult? Why? Add any additional reflections.

Something that gave me difficulties was the static variables. I forgot that they would increase through both objects. This gave me trouble for quite a bit until I remembered how this was similar to a “numberOfSomething” counter. The last slide was also quite difficult at first. Once I noticed that the value of the parameters didn’t matter that much, I found it easier. I slowly went through the code and wrote down what happened step by step on a notepad. I think that the static variables were hard as I was focused on believing that each object’s values were unrelated to others. It only became easier once I recognized the similarity to a counter. The last slide was difficult as it involved calling other constructors from another. This was hard to visualize in my brain until I wrote it down. I think that writing stuff down on a notepad is useful and I’ll use it more when I code.