This post originated from an RSS feed registered with Agile Buzz
by Piergiuliano Bossi.
Original Post: Flexus points
Feed Title: theboxx
Feed URL: http://docs.codehaus.org/dashboard.action
Feed Description: Ideas, thoughts, feedback, rants and some noise about XP, agile, ruby, Fitnesse, etc.
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.
Previous Topic
