Uncontrolled coupling - Singletons, just say NO!

We’re developing some code for a client. There’s a standalone server, which we’ve completed, and a small stub of code that allows the client’s existing system to talk to our new server in place of the old thing they used to talk to…

This morning I stubbed out the new stub and put together a test harness project. Unfortunately, due to the way the client’s code is coupled it could prove difficult to test the new stub…

The stub replaces some code that talks to a serial port with code that talks via sockets. The serial port code is neatly isolated behind an interface, we simply need to write a sockets based implementation of the IModem interface and plug it in. That part is actually quite easy, testing it isn’t.

The application makes heavy use of singletons. The way they’re being used is just the 90’s version of global variables. The first sign of trouble is when we try and link our test harness. The linker complains about masses of code that we didn’t realise we were using… After chasing down the files we need to include in the build we finally get the test harness to link and run and then find that due to the way the singleton that deals with ‘application configuration’ works we need to have the correct MSMQ infrastructure set up on the test box even though this part of the code has absolutely nothing to do with MSMQ… We’re not in a position to refactor the coupling away, we don’t currently have the correct set up on the dev and test box and we dont have dev tools on the MSMQ infrastructure test box.

The app uses the MS cure for brain-dead physical design (precompiled headers built via stdafx.h) so there’s no chance that we can link with our own configuration object in place of the one that requires something that requires something that doesn’t really need MSMQ but initialises it anyway…

Dontcha just hate going back to the dark ages…