When module calling gets ugly
- by Pete
Has this ever happened to you? You've got a suite of well designed, single-responsibility modules, covered by unit tests. In any higher-level function you code, you are (95% of the code) simply taking output from one module and passing it as input to the next. Then, you notice this higher-level function has turned into a 100+ line script with multiple responsibilities.
Here is the problem. It is difficult (impossible) to test that script. At least, it seems so. Do you agree? In my current project, all of the bugs came from this script.
Further detail: each script represents a unique solution, or algorithm, formed by using different modules in different ways.
Question: how can you remedy this situation?
Knee-jerk answer: break the script up into single-responsibility modules.
Comment on knee-jerk answer: it already is!
Best answer I can come up with so far: create higher-level connector objects which "wire" modules together in particular ways (take output from one module, feed it as input to another module). Thus if our script was:
FooInput fooIn = new FooInput(1, 2);
FooOutput fooOutput = fooModule(fooIn);
Double runtimevalue = getsomething(fooOutput.whatever);
BarInput barIn = new BarInput( runtimevalue, fooOutput.someOtherValue);
BarOutput barOut = barModule(BarIn);
It would become with a connector:
FooBarConnectionAlgo fooBarConnector = new fooBarConnector(fooModule, barModule);
FooInput fooIn = new FooInput(1, 2);
BarOutput barOut = fooBarConnector(fooIn);
So the advantage is, besides hiding some code and making things clearer, we can test FooBarConnectionAlgo.
I'm sure this situation comes up a lot. What do you do?
