Tiny, single-purpose class: ResultToFunctionAdaptor

Every now and then I need a small piece of functionality that perfectly fits into a single, minimal-behavior thus single-purpose class. This time I am developping a Adobe Flex application that uses the RemoteObject facilities. Before invoking a method on a RemoteObject, you have to add two event handlers that will be called with a ResultEvent or a FaultEvent respectively. Typically in the “onResult(event:ResultEvent)” function, one takes the result of the event and calls another function or update a view.

In my application, this pattern had been applied at numerous locations until I decided to introduce a simple but effective helper class.  A ResultToFunctionAdaptor is a helper class that has an event handler for a ResultEvent and calls another handler with the result of that event.

public class ResultToFunctionAdaptor
{
	private var _handler:Function;

	public function ResultToFunctionAdaptor(handler:Function) {
			this._handler = handler
	}
	public function onResult(event:ResultEvent):void {
			_handler.call(this,event.result);
	}
}

Using a ResultToFunctionAdaptor I can now encapsulate the event handling and work with Functions only. For example, my (Time)SlotService can be used like this:

...
new SlotService().getAllSlots(fromDate,toDate,showSlots);
...
public function showSlots(slots:Array):void {
    ...
}

and the implementation of SlotService>>getAllSlots(start:Date,stop:Date,callback:Function) contains:

aRemoteObject.getAllSlots.addEventListener("result", new ResultToFunctionAdaptor(callback).onResult);

This class has been added to the Dunelox library which is a collection of ActionScript classes that provides a micro application framework for Adobe Flex applications.

Helper classes considered bad OO

Too often developers put logic in so-called Helper classes.

This practice of SPOD (Single Point of Definition) results in a higher level of reusability, so it seems.
But in fact introducing these procedural structured behavioral methods impose a rigid structure.
First of all, (other) developers need to be aware that such Helpers exist to work on their objects.
Secondly, because behavior that should have been defined in the class of the object, is now defined elsewhere. The possibility of re-using such behavoir by inheritance is now unavailable. You cannot just extend an Helper class too!

Helper classes are intended to provide context independent behavior that cannot be assigned to a particular class of objects. Good examples are conversion methods e.g. formatting a Date or accessing external resources to prevent code duplication.

But what about the behavior required to associate one object to another if none of them is a container? Who is responsible for creating the link and proper setup of both references? Sometimes you cannot add behavior to either one of both sides (depends on whether you specified navigatability on the association ends). In this case, the Mediator pattern can be applied.

Application Diagnoses Itself

How can I provide programs with self diagnostic behavior? How can I implement this in a way that has low impact on the way I write programs (or Java classes to be more specific). If programs could run such a self diagnose then perhaps it takes less time to find the cause of an observed problem.

These thoughts are sprung when I found an error in an application that went into production just a few days earlier. The problem itself was easily fixed (just a typo in some properties file) but I was a bit surprised that obviously my tests did not cover this particular execution path. Sure, I should have written more tests to have a higher coverage (JCoverage can tell me what percentage), but what if I had programmed this behavior differently(how?) such that a self diagnose run would have detected it?

So I started coding some classes and apply them to this particular application just to find out what the benefits could be and what efforts are. See project SelfDiagnose for my progress on this.

Don’ts

Another example of how negative publicity can have a big learning effect (if understood). From a new entry @ slashdot about Multi-links, I surfed to WebsitesThatSuck. The authors are committed to show the worst designs that live on the web.

With respect to Software Design, my dialy work, a similar initiative has been around for a few years. In response to the popular Design Patterns book written by the Gang of Four, others introduced the Anti-Patterns as a means to teach designers about the dont’s in the design of systems using Object Technology. You can contribute to them using the Anti-Patterns Wiki.