Basically our market simulator is a tool to parse the production logs, inject them into the application and verify that the behaviour of the application is correct. (A commercial tool called VeriFIX does more or less the same job, but we need more flexibility)

It will be used when upgrading to newer releases and when installing a new instance of the Fix Routing Engine.
It is end to end black box testing, with some reports to understand if everything is still processed by the Fix engine as it’s supposed to be.

From a new joiner on the Fix support team we had the request to show in the reports not the tag values for the processed fix messages but the description and (not a surprise) even a senior developer of the client was asking the same feature.

Looking then to the full picture we are always playing with the same object, the famous Fix message, with his near to 1000 fields but we use friendly tag descriptions on tests and code, tag numbers on the DSL: concise and quicker to understand by the Fix team and finally again tag descriptions for the Fix support team in the test reports.

Every context has its own language, even inside the same division, even in the same domain.

More on financial fun soon, since the next step is a Domain Specific Language for playing with these things

Do you want to remove all these if? What’s wrong with the ifs?

So, it’s better to clarify something.

First of all it’s not about removing every single if, it’s about having a more flexible, maintainable and readable code.

A long case (or if then else) statement can be difficult to read and follow, maintenance can be painful.

The first category of if to get of rid of, the most immediate it’s the type based if.

There is clear: something is wrong, the responsibility is not where the if is but in the class itself.

So, an example.

On a project (in a Domain Driven Architecture) we had a fairly long “if type then, else if type then, etc…”

The if chain was on different Tasks Types in a workflow engine.

Let’s imagine that the workflow is an engine for a touch-less car wash system.

So you have, for example:

InsertCoinTask
2-StepHeatedPreSoakTask
HighPressureTouchFreeWashTask
Tire&WheelCleanerTask
HighPressureRinseTask and so on.

Every task depends on the completion of a previous one and might need a run time configuration.

So, the code was something like this:

if (task is InsertCoinTask)

{ Configure(task as InsertCoinTask) }

else if (task is StepHeatedPreSoakTask) {

Configure(task as StepHeatedPreSoakTask) }
...
Inside of a class called TaskServiceConfigurator, were for example a Configure method was implemented like:

private Configure(Tire&WheelCleanerTask task)
{
task.TirePosition = touchFreeWashTask.LastCarPosition;
}
The different configure methods inside that class (then private!) were setting previous tasks settings, values and so on.

So, pain points:

- The long if: you can easily forget to configure when adding your task to the workflow to add it there

- Private configuration methods: difficult to test, not only the configuration but also when testing the task itself

- Public setters on the tasks: since each task is configured inside the TaskServiceConfigurator all the setting came from there

Solution to this has been a double dispatch.

We added on the Task Interface a method Configure with the ITaskServiceConfigurator as a parameter, like this:

ITask
{
Configure(ITaskServiceConfigurator configurator)
}

Tire&WheelCleanerTask is an ITask and the Configure implementation might look like:

Configure(ITaskServiceConfigurator configurator)
{
tirePosition = configurator.LastCarPosition;
...
}

The above example probably is too stupid, but the key point is that the LastCarPosition depends on other task (performed or not) it’s really a run-time configuration, a real time dependency between tasks.

I found easier to test the tasks, passing a stubbed configuration and the configuration itself had a definitely better code coverage.

Any better solution to this code redesign is more than welcome.

(Task names are taken from this page: http://www.autec-carwash.com/ )