Flexus points

A few days ago I found myself implementing fixtures where some fields where date-liked typed. To be precise, the customer was specifying dates in Italian format (ie: DD/MM/YYYY, like 24/11/2005), and corresponding fields in domain objects were typed with custom-type dates, incapsulating java.util.Calendar (to be honest, java.util.Calendar defines one of the worst hierarchies in whole jdk libraries; I still wonder what was drinking or smoking the designer of that hierarchy – but that’s another story).

Fit has parsing facilities built-in for java scalar types and a few others (ie: java.util.Date). Therefore when you specify values of custom types you have a few alternatives:

  • don’t use custom types in fixtures, but rely on some other standard representation (ie: a date may be decomposed in 3 integer fields) ==> this seem somehow unnatural and cunning
  • the fixture can override method public Object parse(String s, Class type), which will be called polymorphically by TypeAdapter while parsing table contents ==> this is very good when you want to confine parsing facilities in fixtures only, but has the drawback of being limited to one hierarchy line only (unless duplicated in many fixtures, of course)
  • the custom object T may define a static method like public static T parse(String s), which will be called via reflection by TypeAdapter ==> this is best choice when you want to reuse the parsing facilities among different fixtures, but has the drawback of pollute application code with parsing services just for testing purposes

Third option was perfectly suited for the situation I was facing. As a side-effect I have redefined toString method such that for every T t instance t.equals(T.parse(t.toString())).

Some months ago there was a discussion on the Fitnesse group concerning the possibility of having pluggable custom TypeAdapter classes, so that every fitnesse project can define its own parsing rules, common for all the fixtures, without polluting domain objects: I think it would be the best possible option, but we have to wait until a plug-in architecture will be defined in Fit for that.

In the end the message is: you can put a lot of extension points (or flexus points) in your design, especially if you are developing a framework. Nevertheless there will always be situations that your design is not able to tackle out of the box. That is to say, your design cannot be closed (in OCP sense) against any changes no matter what. This is true whether you are developing in a traditional, prescriptive manner or if you are an agile, evolutive follower.

PS: parsing mechanisms are well described in the wonderful Fit for Developing Software, from Rick Mugridge and Ward Cunningham, definitely a must have if you happen to build fixtures in your projects.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: