When module calling gets ugly

Posted by Pete on Programmers See other posts from Programmers or by Pete
Published on 2012-06-01T14:52:37Z Indexed on 2012/06/01 16:49 UTC
Read the original article Hit count: 273

Filed under:
|
|

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?

© Programmers or respective owner

Related posts about java

Related posts about design