Implementing the new AcceptEx server

Following my tooth brush revelation about AcceptEx earlier in the week I found some time today to test out my ideas.

The implementation went pretty smoothly. It was helped by the fact that I had a previous attempt at using AcceptEx floating around. It was helped more by the refactoring that I’d done recently and the fact that it was easy to take the tests I had for the listen/accept version of the socket server code and adjust them to work with the new AcceptEx version.

The first time we wrote an AcceptEx version of The Server Framework we ended up with a mass of duplication. As I later admitted, the coupling in the original framework sucked and this showed clearly in the AcceptEx and UDP versions of the servers. Now things are better. Since we’ve broken apart the server into several objects, each responsible for one aspect of the work we found that doing an AcceptEx version meant writing one new class and reusing everything else; isn’t that the way it’s supposed to work? It’s true that this server doesn’t do as much as the previous attempt, but it does what we need, and we never really found a need for the other one…

I’m quite pleasantly surprised that the new server class doesn’t require any duplicate code. I needed to make a small change to the CAsyncSocket class that is shared by both servers, and would need to make more changes if I wanted to incorporate all of the features that the old AcceptEx server supported but if that ever happens we’ll slip an interface in first and any client code would simply work with IAsyncSocket and be easy to switch between either type of server.

The tests really helped. The fact that I’d already got some coverage in the socket library meant that I could write a fairly complicated test straight away. I was only changing the way connections were accepted and testing this area required lots of mocks and things to connect to and all sorts. Of course all that was already written and so it was just a case of reusing it for the new tests.

I’m now a strong believer that it’s better to some tests than no tests; even if it’s just one or two simple ones. It may look daft to have an empty mock library project and a test harness project with one simple test for a simple object in the library but if you can force yourself to put the scaffolding in it makes it easy when you need to write the first real test. I’ve integrated test projects into almost all of our libraries now. It’s mindless work, but sometimes you need a bit of mindlessness, and it pays off in the long run. When you’re all stoked up to write new code you don’t want to do the mindless test project creation, but if it’s already there, you’ll use it…