an acid test for method sanity

So, I just looked at a method call in an online tutorial and found this fairly simple code.

// Initialize the hasher without portable hashes (this is more secure)
$hasher = new PasswordHash(8, false);

What’s wrong with this? Not much maybe. Or maybe a lot. I have an acid test for method signatures: can I determine what the arguments are from the method name and parameter type(s)?

First things first, the first parameter ‘8’ may be given a name in production code, as might the ‘false’. That’s ok – I’m not interested in the quality of the calling code, just the signature of the method.

The crux of the problem – what is this method / constructor asking for? I read aloud the method with parameter types in place and try to determine the purpose of them. In this case I read out the following:

new Password Hash int boolean

What does this mean? No idea.

At first glance this seems like an ‘out there’ naive view of code, along the lines of ‘never use the String class’ but I feel this is a fundamental part of writing better code. Here I would prefer to create a ‘default hasher’ using a factory method maybe, assuming that I need an int and boolean to create a Password Hash. Now let me override the int and boolean with appropriate setters, e.g.

$hasher->setFluidOunce(8);
$hasher->setFrothy(false);

And there you have it, my acid test for method sanity.

String.intern aka “I never knew that…”

Ok, so I’m trying to fill in any gaps in my java knowledge. First thing is going through my fairly comprehensive SCJP 1.5 study book. Mainly common stuff I’ve used enough of but the odd thing is of interest. Today I found the ‘intern’ method on Strings. I’ll explain.

The typical Java developer is aware of the following:

• Strings are immutable.
• Strings typically live in a String pool.
• Strings should be checked for equality using the equals method, not ‘==’.

You can create a String not in the String pool using the the following:

String foo = new String("bar");

What we typically want, though, is String reuse, via the String pool. An interesting method exists around Strings to ensure getting the String instance from the String pool, this method is ‘intern’. Here is the javadoc lifted from the JSE1.7 site:

Returns a canonical representation for the string object.

A pool of strings, initially empty, is maintained privately by the class String.

When the intern method is invoked, if the pool already contains a string equal to this String object as determined by the equals(Object) method, then the string from the pool is returned. Otherwise, this String object is added to the pool and a reference to this String object is returned.

It follows that for any two strings s and t, s.intern() == t.intern() is true if and only if s.equals(t) is true.

All literal strings and string-valued constant expressions are interned. String literals are defined in section 3.10.5 of the The Java™ Language Specification.

Here is a class to demonstrate with tests. It uses the System.identityHashCode(Object) method to show which object reference is being looked at.

import junit.framework.Assert;
import org.junit.Test;

public class StringTest {
	final String test = "test";
	@Test
	public void testStrings() {

		final String stackTest = "test";
		final String stackTest2 = new String("test");
		final String stackTest2Interned = stackTest2.intern();

		Assert.assertEquals("test", test);
		Assert.assertTrue("test" == test);
		Assert.assertTrue(stackTest == test);
		Assert.assertFalse(stackTest2 == test);
		Assert.assertTrue(stackTest2Interned == test);

		System.out.println("id of constant = " + System.identityHashCode(test));
		System.out.println("id of stackTest = " + System.identityHashCode(stackTest));
		System.out.println("id of stackTest2 = " + System.identityHashCode(stackTest2));
		System.out.println("id of stackTest2Interned = " + System.identityHashCode(stackTest2Interned));
	}
}

Use the eight primitive Java types

Java has 8 primitve data types.

Here is a list of them with their size and example use:

boolean – a single bit.
A bit is a single value in memory which can have 1 of 2 values – 0 or 1. Typically in programming, 0 means false and 1 means true but this relationship does not exist in java. A boolean has to be true or false, but this rule does not hold for the Boolean object.
Example of its use would be where an object has an ‘is’ or ‘has’ attribute, e.g. person.isDeceased(), person.isEligible();

short – a 16-bit number.
Of the 16 bits used, 1 of the bits is used to determine whether the value is positive or negative. This means the minimum value represented is -32768 and the maximum is 32767.
It is rarely used as an int is typically used for counting things and a Long is typically used for the Id field of an entity.

char – 16-bit character representation.
When used directly it represents a character. It can however be used as a number – it has MIN_VALUE and MAX_VALUE as do other number types, e.g. short, int, long. This does also mean it can be used with the normal mathematical operators such as +, -, % etc.

int – 32-bit integer numbers.
Always occupies 32 bits, regardless of processor, java version etc.
A typical usage would be counting the elements in a list or some returned results. Min value is -2147483648 and Max value is 2147483647. An int is often used even when the value expected would fit into a short. This is just force of habit I think.

float – 32-bit floating point.
This is used for calculating values with numbers after the decimal point, e.g. 10/3. Min value is 1.4E-45
and max value is 3.4028235E38. It shouldn’t be used for currency as it deals with approximations. Running the following:

System.out.println(1.03 - 0.42);

will output

0.6100000000000001

long – 64-bit integer
This is typically used for very large numbers – the min is -9223372036854775808 and the max is 9223372036854775807. A long is typically used for the id field of an entity persisted in the database.

double – 64-bit floating point number.
I never use doubles, I never see doubles used and doubt I will see them used. I don’t do a lot of mathematical computation though – I typically write CRUD apps and have code around the workflow of CRUD, e.g. validation, converting to and from DTOs, persistence.

Hope this helps give an idea of the different types. I think the main concerns are whether you want to use whole numbers or not and if so the concern becomes how much space do you need to represent this number – generally the smaller the better but… shorts are rarely used even when appropriate.

OO Concepts – Abstraction

Abstraction is one of the key ideas behind Object Oriented Programming, but the word has a few meanings even just within the field of OOP. The general concept is something I refer to as not having to worry about details. Here are some of the meanings of abstraction in OOP:

Abstraction and polymorphism
Some conversations are about levels of abstraction. An example may be that we want our class to log messages but without worrying about how or where to. A Logger class may provide us with a level of abstraction – we can call methods on our Logger without worrying about its implementation. Being able to deal with different Logger implementations, just using its inteface, is a form of polymorphism, and an example of how the key parts of OO interact.

Abstraction and inheritance
When we extend a base class and provide a specialisation, we typically get some functionality for free. We don’t worry about how this functionality works, we just get it. The most common example is java.lang.Object. If we don’t explicitly extend another class we will extend this one by default. It provides our class with toString, hashCode and equals methods, maybe some more.

Levels of Abstraction
In OO we typically layer our applications and deal in abstractions. This enables our code to work at a particular level of abstraction. Imagine code to validate a customer and, if valid, persist it. If it fails it will raise an alert. What ‘level’ of abstraction do we want to work at? I would imagine a method call for each of those tasks. Any more and maybe we don’t have enough abstraction. Any less and maybe there is too much – a problem that I personally don’t think gets enough attention. Anyway, here are some examples of implementing this class with differing levels of abstraction:

/* 
 * BAD - TOO MUCH ABSTRACTION - 
 * here is an example where we get that the service will 
 * try to persist the Customer but how and whether there is
 * validation or not is lost. We would need to dig around - starting with
 * the call to super.perform - this could be doing anything.
 */
class CustomerService { // too much abstraction....
  public void persist(Customer c) {
     super.perform(c, getDataStore()); // who knows what this does?!?
  }
}

Here we have an appropriate level of abstraction – not much digging to do here, we even know how errors are handled.

/* 
 * GOOD - we haven't hidden what the purpose of the method is. We can see what it will do
 * just as good as if we commented inside.
 */
class CustomerService { // right level of abstraction
  public void persist(Customer c) {
     try {
       validator.validate(c);
       customerDao.persist(c);
     } catch (Exception e) {
       log.error("error in persist: " + c, e);
       alertService.alert("error persisting customer: " + c, e);
     }
  }
}

Now we have not enough abstraction. We have details we don’t want to be working with:

/* 
 * BAD - not enough abstraction - 
 * we are working at too low a level, the opposite of the first example. we specify 
 * every little detail, micro-managing each step. 
 */
class CustomerService { // not enough of abstraction
  public void persist(Customer c) {
     DataStore ds = ServiceLocator.getDataStore();
     PersistService ps = new PersistService(ps);
     try {
       Validator validator = new Validator();
       validator.setMode(STRICT);
       validator.setTarget(c);
       validator.validate();
       if (validator.hasErrors()) {
         throw new ValidationException(validator.getErrors());
       }
       ps.beginTransaction();
       ps.persist(c);
       ps.commit();
     } catch (Exception e) {
       Logger log = LoggerFactory.getLogger();
       log.error("error persisting " + c, e);
       if (ps.inTransaction()) {
          ps.performRollback();
       }
       AlertService alertService = new AlertService(getInitialContext());
       alertService.alert("error persisting customer: " + c, e);
     }
  }
}

It’s easy to write code like this, I’ve written it myself. The problem is that when I go back to this code my eyes gloss over and I just don’t want to have to take in all of that complexity. Am I concerned here about which persistence mechanism? No, it is as if this method should just give out simple orders – validate, persist – or log, alert. How these are implemented are the respective responsibilities of the Validator, Persister, Logger and AlertService – implementations I don’t want to worry about here.

#8 of 99 Problems – Eliminate consecutive duplicates of list elements.

This post and the original question are licensed under a Creative Commons Attribution-Share Alike license and all code is released to the public domain.

This problem again relies on the functionality built into Scala collections and I don’t add much to the original solution.

Problem:
If a list contains repeated elements they should be replaced with a single copy of the element. The order of the elements should not be changed.
Example:

var result = compress(List('a, 'a, 'a, 'a, 'b, 'c, 'c, 'a, 'a, 'd, 'e, 'e, 'e, 'e))
println("Result = " + result)

Output: Result = List(‘a, ‘b, ‘c, ‘a, ‘d, ‘e)

Answer:

object Class08 extends App {

  def compress[A](ls: List[A]): List[A] = ls match {
    case Nil       => Nil
    case h :: tail => h :: compress(tail.dropWhile(_ == h))
  }

  var result = compress(List('a, 'a, 'a, 'a, 'b, 'c, 'c, 'a, 'a, 'd, 'e, 'e, 'e, 'e))
  println("Result = " + result)
}

Original Question here: http://aperiodic.net/phil/scala/s-99/

This is a good example of using dropWhile, classified as a ‘subiterator’ here – http://www.scala-lang.org/docu/files/collections-api/collections_43.html

#7 of 99 Problems – flatten a list

This post and the original question are licensed under a Creative Commons Attribution-Share Alike license and all code is released to the public domain.

This problem is deeply rooted in the functional programming side of scala, which is not my strongest subject as I come from an OO background. I cannot add to the original solution given and merely post the solution here for completeness – there is no point posting 90 or so of 99 problems 🙂

Anyway, here it is…

Question:
Flatten a nested list structure.
Example:

var result = flatten(List(List(1, 1), 2, List(3, List(5, 8))))
println("Result = " + result)

Output: Result = List(1, 1, 2, 3, 5, 8)

Answer:

object Class07 extends App {
  def flatten(ls: List[Any]): List[Any] = ls flatMap {
    /* this is an example of pattern matching on type, here
     * the code says 'if this item is itself a list'
     */
    case ms: List[_] => flatten(ms)
    // this matches any other item
    case e => List(e)
  }
  var result = flatten(List(List(1, 1), 2, List(3, List(5, 8))))
  println("Result = " + result)
}

Original Question here: http://aperiodic.net/phil/scala/s-99/

#6 of 99 Problems – is a list a palindrome in scala

This post and the original question are licensed under a Creative Commons Attribution-Share Alike license and all code is released to the public domain.

This is more involved than previous problems. We are checking if a list is a palindrome and we will do this, as in previous problems, using pattern matching on the List. I use 3 scenarios which would be ifs in Java.

1. If the list is less than 2 items it is empty or has 1 item. I count these as being palindromes.
2. If the head (first item) and the last (last item) are the same then it might be – let’s recurse 🙂
3. If 2 items or more and first and last differ then return false.

This means using an if in our case to check first and last items in the 2nd scenario.

A note on pattern matching: The line of code below will create 2 values from the list – head and tail – where head is the first item and tail is everything else. It makes matching and recursion simpler.

case head::tail => // do something...

Anyway, here’s the code:

Question:
Find out whether a list is a palindrome.
Example:

var result = isPalindrome(List(1, 2, 3, 2, 1))
println("Result = " + result)

Output: Result = true

Answer:

import scala.annotation.tailrec

object Class06 extends App {

  var result = isPalindrome(List(1, 2, 3, 2, 1))
 
  @tailrec // we expect tail-recursive optimization
  def isPalindrome(l:List[Any]):Boolean = l match {
    case yes if(l.length < 2) => true  // true if small enough
    case head::tail if (head==tail.last) => isPalindrome(tail.init) // recurse without first and last
    case _ =>  false // this is like an else
  }   

  println("Result = " + result)
}

Original Question here: http://aperiodic.net/phil/scala/s-99/

This shows some of the features of pattern matching in scala. The word yes is just a name I’ve given to the first case which runs off the if condition. There is a convention to use an underscore for catch-all cases, a convention I follow here. The original list of questions doesn’t show anything beyond list==list.reverse but I think this answer is a good example of recursion and pattern matching.

#5 of 99 Problems – Reverse a List in scala

This post and the original question are licensed under a Creative Commons Attribution-Share Alike license and all code is released to the public domain.

This example reverses the list purely as an example of writing a recursive function in scala. Like the other examples I’ve written, the aim is simple code, not necessarily the most performant and not using built in List functionality per se.

Question:
Reverse a List
Example:

var result = reverse(List(1, 1, 2, 3, 5, 8))
println("Result = " + result)

Output: Result = List(8, 5, 3, 2, 1, 1)

Answer:

object Class05 extends App {

  // l is Parameter of type List[Any] and return is of type List[Any]
  def reverse(l:List[Any]): List[Any] = l match {
    case Nil => l // if empty list passed return it and stop recursion
    case head :: tail => reverse(tail) ::: List(head)     // recurse with all but first items, appending first item.
  }   

  val result = reverse(List(1, 1, 2, 3, 5, 8))
  println("Result = " + result)
}

Original Question here: http://aperiodic.net/phil/scala/s-99/

This is an example of a pattern of writing recursive functions but breaking out of the recursion when our list is exhausted. I must admit – the original 99 problem post provides more elegant solutions than I am capable of and is worth a look to see other ways of achieving the same thing,

#4 of 99 Problems – count items in a list

This post and the original question are licensed under a Creative Commons Attribution-Share Alike license and all code is released to the public domain.

The easiest way to get the item count for a List in scala is to use the size or length functions provided by List. This answer is an example of writing a function in scala, more specifically a recursive function without side-effects.

Question:
Find the number of elements of a list.
Example:

var result = length(List(1, 1, 2, 3, 5, 8))
println("Result = " + result)

Output: Result = 6

Answer:

object Class04 extends App {

  // Outer function:  
  def length(l:List[Any]):Int = {

    // Inner function:
    @tailrec
    def length(count:Int, l:List[Any]):Int = l match {
      case head::tail => length(count + 1, tail) // recurse
      case Nil        => count                   // empty list so return count
    }

    // call that recursive inner function with initial state:
    length(0, l)
  }

  val result = length(List(1, 1, 2, 3, 5, 8))
  println("Result = " + result)
}

Original Question here: http://aperiodic.net/phil/scala/s-99/

This is an example of a pattern of writing recursive functions – an outer and an inner function. The outer function creates the starting point and calls the inner recursive function which exhaustively iterates, in this case through a list.

Scala HTTP Server pt 3 – Request case class

Ok, this is another example of a Case class and, as this is all that’s in this post I’ll attempt some further explanation of this nice feature of Scala.

First, here is the class:

package com.vff.scalahttp

case class Request(method:String, resource:String)

Now, here is the Java equivalent:

package com.vff.scalahttp;

public class Request {

  private String method;
  private String resource;

  public Request(final String method, final String resource) {
    this.method = method;
    this.resource = resource;
  }

  public String getMethod() {
    return method;
  }

  public String getResource() {
    return resource;
  }
}

A case class is a nice construct I typically use for holding data in an immutable way.
Here is the ‘official’ definition: http://www.scala-lang.org/old/node/107