Suppose you have a method that con­cat­en­ates strings, like the method in code snip­pet 1 below. One day, you come to a point where this method does not suf­fice any­more. You need an addi­tional para­meter, to allow the user to place a char­ac­ter between each con­cat­en­ated string. That’s easy, right? You just alter the method, and its sig­na­ture, as in code snip­pet 2.

Works like a charm. We can just wrap this up and leave work early, can’t we?

No, we can’t. What about all the other code in your pro­ject (or in other people’s pro­jects) that uses the method you have just altered? That code now doesn’t work any­more. It doesn’t even com­pile any­more, because you changed the method’s sig­na­ture. Is there a way to pre­vent this from happening?

Continue read­ing

When read­ing or writ­ing XML files in Java, chances are that you are using classes from the pack­age org.w3c.dom which comes bundled with the Java-interpreter. I found these classes very cum­ber­some to use for a small pro­ject. Many calls to factory-methods are needed before it is even pos­sible to start using an XML file. Debugging is even worse since all you get to see are undoc­u­mented instances of imple­ment­a­tions of the inter­faces that are in the org.w3c.dom package.

My atten­tion was recently drawn to another XML parser: NanoXML/Lite. For small applic­a­tions that do not need advanced fea­tures, like DTD val­id­a­tion, NanoXML/Lite provides suf­fi­cient func­tion­al­ity and is very easy to use. For more advanced applic­a­tions there is another parser avail­able, NanoXML/Java, which I will not dis­cuss since I have not used it.

Continue read­ing

Recently I have taken the Functional Programming Principles in Scala class on Coursera to refresh my know­ledge on func­tional pro­gram­ming and to learn a new pro­gram­ming lan­guage. Scala is an object-oriented func­tional pro­gram­ming lan­guage that com­piles into Java byte­code, which allows it to run on the JVM. Because of this, it is pos­sible to call Scala code from other lan­guages that also run on the JVM, and vice versa.

One pat­tern that kept pop­ping up dur­ing the course, was the usage of an accu­mu­lator to store inter­me­di­ate res­ults when mak­ing recurs­ive calls. This pat­tern has always felt a bit odd to me. It feels like a loop that puts some­thing on a list or updates a res­ult for every iter­a­tion, only the recurs­ive approach seems less clear. Let us take a closer look at this phenomenon.

Continue read­ing