From Journeyman to Master

Or should we call it Specification Factory? It all started when James and I were working on a story. We have a Home class that instantiates various classes based on some insane heavy if-else logic. We decided that we’ve had enough of it. James suggested that we could create a Factory and convert the if-else logic to a key of String type instead. I like the Factory idea but not quite happy with having an extra string in our code just for this purpose. Then I remembered the Specification pattern that Ted introduced to us a couple of days ago. What if we use the Specification as the key? You have a map with the Specification as the key and the class you want to instantiate as the value. Then all you need to do is to iterate over the key set of the map and get the value once you find a Specification that is satisfied. A piece of code sample is shown below.

for (Specification spec: classMap.keySet()) {
  if (spec.isSatisfiedBy(someObject)) {
    return classMap.get(spec);
  }
}

Somebody left a comment regarding to my Ruby Gotcha #1 post:

Since you posted this a while ago, you may have since learned of instance variables, which are preceeded by an ‘@’. If not, well here is the proper way to write your setter.

class Foo
  attr_accessor :bar
  def setNewBar=(newBar)
    @bar = newBar
  end
end

Whoever made this comment missed the point here. Yes, the above solution will work. But it’ll only work in this simple case. Whatever language you are using, it’s always a good OO practice to use accessor instead of instance variable directly. This is especially true in a language like Ruby where the instance variable is always private (although it’s very hard to demonstrate this behaviour). In our example, if you have a class that extends Foo, the subclass shouldn’t use ‘@’ to access the instance variable. Instead, it must use the attribute accessor. Then we will end up with the same problem. The correct way to deal with it is to preceed the attribute accessor with ’self’.

The more I learn Ruby the more interesting I find it is. These gotchas is also part of what makes it interesting. Watch out for more posts about them.

Jeff said:

“Note that each facade method has its own transaction. So if one of the task fails, it will just rollback itself, not the whole bundle.” I thought about this as well, but just assumed it had been addressed before. Maybe it hasn’t been brought up, though? I also wonder if this is one way we could get some good performance gains. If we could come up with a way of injecting one Unit of Work into multiple facade calls we could address the rollback issue, and possibly make things faster by not ditching our object caches after each facade method (transaction). For example, our battery oil process task bundle must make about 10 separate facade calls. Perhaps our workflow stuff should sit just below the facade instead of above it.

Yes, I heard that this problem is being dealt with using nested transaction supported by Toplink. But I think it might be an overkill for us. Do we really need nested transaction? Do we need to do partial commit/rollback? It doesn’t solve the duplicate lookup issue, either. It’s gonna be one more thing that ties the application to Toplink. So I like putting the workflow stuff behind the facade idea better. Actually, there is a class called InTransactionTaskBundle that does just that. It performs as same as any other TaskBundle except that it’s behind the facade and uses domain objects directly. I created this class and refactored a process bundle with about 10 tasks. The refactoring was straightforward and took only one or two hours.

Our project has the first release date set to be March of the next year. Currently, every team other than the one I’m in is in scenario testing or performance tuning mode. I’m not quite sure how things are going with them. But I myself can see a couple things that will bite us if they are not dealt with before or soon after the release.

Process bundle

Process bundle is a pattern we use to group tasks that need to be executed together and in order. It’s done as something like this:

class ProcessBundle {
  public void doTask() {
    FacadeFactory.getFacade().doTask1();
    FacadeFactory.getFacade().doTask2();
    .
    .
    .
  }
}

Note that each facade method has its own transaction. So if one of the task fails, it will just rollback itself, not the whole bundle. If some other process modifies the result of task 1 between the time task 1 finishes and task 2 starts, task 2 will have incorrect input. Since most of the tasks in a bundle use the same set of domain objects, we are also doing some duplicate lookup here.

Batch

So you develope a perfect, highly responsive web based enterprise application and release it to the client. What’s the first thing that’s gonna pop up? The client wants a batch process like the one they had in the good old mainframe system! That just throws the whole perfectionism away, doesn’t it? But you gotta face the reality. A batch process is even more important in a web environment. Say our application takes 5 minutes to process 100 wells. It’s not unusual for our client to process thousands of wells at a time. Being an optimistic person as I am, I say it’ll take half a hour to process those wells. Now you are facing a web browser or session timeout issue. What if somebody clicks the Back or Refresh button? Most of the enterprise level web applications will face the same problem. What do you do? Well, first you implement a job queue. Then you create a super responsive web page to monitor and maintain it.

That’s my thought. Welcome any comment.

Let’s look at a method written in Java:

void printMyTransactions(MyAccount myAccount) {
  Currency currency = myAccount.getCurrency();
  printTransactions(currency.getFormat());
}

The problem with this method is that it shouldn’t know about the existence of Currency. In other words, our method doesn’t own an instance of Currency. The fact that MyAccount has a Currency in it should only be known to MyAccount itself. So it’s better to write this method as a delegation:

void printMyTransactions(MyAccount myAccount) {
  myAccount.printTransactions();
}

This is the Law of Demeter for functions. It states that any method of an object should call only methods belonging to:

• itself
• any parameters that were passed in to the method
• any objects it created
• any directly held component objects

Following this law will help reduce the coupling in your program. I already see quite a few places where we can apply this law in our project.

As I’m slowly gradually learning Ruby, I find a number of stuff that can categorized as gotchas. I would like to record them here for future reference. The following is one of them. I personally think it’s pretty big.

Normally, methods within a class can invoke other methods in the same class and its superclasses in functional form (that is, with an implicit receiver of self). However, this doesn’t work with attribute writers. Ruby sees the assignment and decides that the name on the left must be a local variable, not a method call to an attribute writer.

class Foo
  attr_accessor :bar
  def setNewBar=(newBar)
    bar = newBar
  end
end

foo = Foo.new
foo.bar = 10
foo.setNewBar = 100
foo.bar -> 10

Ruby stored the new value in a local variable of method setNewBar= instead of using the attribute writer. I can see this causing some nasty bugs.

More on Ruby Gotchas to follow.

Technorati Tags: gotcha, ruby

Assigning a collection to another collection is okay in most cases. But today I encountered a case where the assignment doesn’t quite work. See the following block of code.

class Foo {
  private Collection aCollection =
    new TreeSet(new SomeKindOfComparator());

  public void setACollection(List aCollection) {
    this.aCollection = aCollection;
  }
}

The intent is to keep the collection sorted and avoid duplication. But as soon as the assignment in the setter happens, the instance variable aCollection’s reference is changed to be the List. There won’t be any error or exception at either compiling time or runtime. You will be wondering why that collection is not sorted and contains duplicate entries.