Friday, November 6, 2009

Sand stays. All else changes. (Jawa Programming 2)

A Jawa programmer? But this R2 unit has a bad motivator. Enough! Pay attention, sit up straight and for the love of all that is good and decent try and look like you’re trying.

I actually read somewhere that daydreamers tend to be more productive than average. I suppose it has to do with how much brain power is actually used pretending to be deeply engaged in some activity other than slacking off, and making sure the people around you are aware of the faces you are making at your work when you are trying to look as if you are doing it. I know I tend to be quite productive when I haven’t a care in the world. I mean when I am skipping and smiling and daydreaming about fairies and unicorns and frolicking in the woods, and not worrying about getting beat up for it because I am bigger than everyone and skipping is good for your endurance and all-around ass-kicking power, I get a lot done. Why is that? You, see skipping engages the muscles of the thighs and calves and causes them to demand an increased blood flow as well as muscle building proteins… Oh, the other thing. Because, I am smart. See, I could furrow my brow and stare intensely at the thing that is in some respects an impediment to my doing what I like, frolicking or kung fu or drawing robots or what-have-you, or I could get it done quickly and correctly, not only maximizing the amount of time I have to frolic and leap tall buildings and such, but also stimulating the release of reward chemicals in my brain with a self-serving neuro-synaptic pat on the back for a job well done.

Back to solving the world’s problems err… this Java lab. I bet I could solve some of the world’s problems. I am pretty smart and I care about umm… things.

JAVA! WJ-2752-6E Lab 5 Exercise 1:

In this lab we have five tasks: Modifying the Bank class, Modifying the Customer Report class, Deleting the Current TestReport class, Copying the New TestReport class, Compiling said TestReport class, and of course running said TestReport.
Briefly, seeing that the other tasks do not require much in the way of completion of the previous tasks I am going to do them slightly out of order. This I can do because in the magical world of make believe I encountered a wizard who granted me powers to peer through project dependencies and traverse the points of view of stakeholders near and far. Some psychologists or another might say no Tom it is because you have an IQ over 140 on the Wechsler culture fair that you can do this. Personally, I find it hard to believe that anyone would prefer hearing about my psychometrics to hearing about wizards.

Anyway…

The work breakdown at a level just above this one (the lab assignment) has only three tasks: “Do the thing to the bank thing.”, “Do the thing to the one report thing.” and “Do the thing to the other report thing.” The thing I have to do to the other report thing is half done already because of the way I have chosen to do this lab in Eclipse. I just have to copy the new TestReport class from the folder I have installed it in. I am going to open it in Notepad++, just because I don’t want NetBeans (my default Java editor) to draw me in with its pleasant came with my new JDK smell. It’s not too hard to find files on my computer since I make adequate use of shortcuts. I really have been meaning to pick up some books on topology. I really expect it to be a worthy distraction that might lead to revolutionary advances in data, file, and object modeling.

I just need to make sure my imports are reflective of the new package… and ok, back to step one. I should probably fix all the import statements in all the classes while I am doing that… ok, done. Now all of our classes are talking to the right classes in the right packages.

In task one, we are changing all of the instance variables and methods of the bank class to static. After a typing the keyword static a few too many times to feel like a genius and then copying and pasting the rest in, we have now introduced a bunch of errors that we are going to fix in a manner different than un-introducing the causes of them namely the static keyword. A little peek at the UML model (still level 1) to make sure our publics aren’t supposed to be privates, and everyone is protected by their hash signs, and all that rot, and we are ready to move on to the next task.
I had a few variables that I had to make local to the methods that used them to bring the bank class in line with the UML diagram. I also had to turn the constructor private. All the errors went away after I realized I only had to make the methods and variables static, not the constructor. Apparently we are not allowed to make constructors static. I suppose that makes sense… sort of. Since the constructors belong to the instances of the class… sort of.

Task two has us modify the CustomerReport class to access the bank class as a utility class. As it stands now all the errors are gone only the warnings pertaining to no accessing the Bank class in a static way remain, and the code runs. Since my customer report class instantiated the bank objects by referring to them with a lower case to differentiate them from the Bank class modifying this class was simply a matter of capitalizing the bank in bank.method() when those static methods were called.

On a side note: static integer variables with a constructor that increments the variable can be used to keep track of the objects. Just in case my gibberish was to passive in voice, we are done with lab 5 exercise 1 now, and we didn’t peek at level two at all. We are good.

No comments:

Post a Comment