Atelier Clockwork

Pattern Mismatch

The Hazards of Working in Too Many Languages

When I was doing very simple Java development, I didn’t make too many stupid mistakes working on it. I think the only really big flaw in the earliest code that I wrote was using far too many try/catch blocks. Loading SQL, parsing the data into objects, and returning them didn’t require much in the way of control flow or advanced languages features.

Now that I’m writing real functions with complicated control flow, I’m starting to find all of the places where Java behaves very differently from Objective-C.

Unit Testing to the Rescue

For all that I’m bad about unit testing my code in Objective-C, I’ve started testing everything that I can in Java as soon as possible. I’m not quite at the “write the tests before the class” level, but as soon as I’ve sketched out the class and think it should work, I write up a unit test and start throwing values into it to make sure it works as expected.

The first Objective-C expatriate sin that I committed was trying to run functions against objects that may be null without checking them first. Definite win for unit testing and passing in strange values to prevent problems in the future there.

The next thing that I ran into was trying to figure out how to emulate the Objective-C @property syntax. I’m spoiled by that bit of syntactic sugar, but I finally moved on and am using private properties and then writing getter methods and setters methods as needed depending on just what I’m doing.

After that, most of my problems are silly things like wanting to use self rather than this before the compiler flags the line. I can’t say this is turning me into a “good” Java developer, but I’m edging towards “decent” and at least the server side work is moving along.