When I realized that I was going to be dealing with legacy code a lot more than I would be creating new applications, I was a bit disappointed. However, as time passed I found that working with legacy applications can be just as interesting, and even adventurous. In this article I'd like to tell you about a mock-up object - an object that looks like a real one, behaves like a real one, but doesn't actually perform the functions of the real object being mimicked. I'll tell you about how I decided to create a mock-up object and integrate it into one of the legacy applications I had worked on, and what the results were. I'll explain how I used the mock-up objects and what pitfalls lie in wait for a developer integrating them into legacy applications.

Please note that in this article I use UML-like diagrams, which in general are not always formally correct UML diagrams. However, I kept UML 2.0 in mind when I was drawing them.

Annoyance
I had been working with quite an old application that frequently used a barcode printer that was used to print a number of different labels with a variety of barcodes on them. The application was designed so that the many tasks the user performed required the printing of barcode labels - that is, it required the use of a barcode printer. For me as the developer who maintained the application and extended its functions, this resulted in quite an annoying outcome - many times, before I could execute the code I was developing, I needed to print a barcode label. For numerous reasons, as you can imagine, I wasn't very happy about it, so I decided to make my life a bit easier.

How the Thing Was Done
The barcode printer interface had been developed some years ago, so first I needed to study how the application interacted with the device. It turned out that it used the Zebra barcode printer family, which supported ZPL II (Zebra Programming Language). The printer was plugged into a serial port of a PC and, to communicate with it, the application used a widely spread serial communication component library, wsc32.dll. The application contained a user object uo_bc_print that had public functions for communicating with a printer and used external functions from the communication library. The user object also had a number of public functions that returned strings with ZPL instructions for each kind of label to be printed. A simplified structure of the user object is shown in Figure 1.

The of_open_port and of_close_port functions are examples of those functions communicating with a printer. The of_build_labelA and of_build_labelB represent the functions that produced ZPL-commands strings, and the of_print function actually sent the command string into the port. As you probably know, the typical interaction with uo_bc_print involved two steps: a client called one of the functions that built a command string and then this string was passed to the of_print function. An example of such an interaction is shown in Figure 2.

It's clear from Figure 2 that the user object uo_bc_print was strongly dependent on the communication library; many of its functions called the external functions from wsc32.dll, such as SioDSR and SioPutC called by of_print. Each time the object was used, it tried to communicate with a barcode printer. This is what I was going to change.

Options to Consider
I wanted to be able to do my tasks without printing barcode labels and even without a barcode printer plugged in. I started thinking about the problem and came to the conclusion that I had three options on how to achieve this. The first was to use some serial port emulation software. In this case everything stayed intact: the external functions would work as if a barcode printer were plugged in and responded correctly. The second option was to make a copy of the user object with all calls of the wsc32.dll functions commented out. Then I could use this copy during development, but would have to replace it with the true version of the object before deployment. The third way was to break the dependency between uo_bc_print and wsc32.dll programmatically; the object would decide at runtime whether or not to use wsc32.dll.

A quick search on the Internet showed that it was hardly possible to find free serial port emulation software that would suit my needs and, even if I found something, it would require some effort to configure it properly (meaning I had to know which answers the external functions expected from a printer - but I didn't). I gave up this option. I considered the second option; the biggest flaw in it was that the user object changed from time to time (existing labels were modified and new labels were added) and I really hated the idea of synchronizing my "dummy" copy with the actual version in the future. So I decided to focus on the third option - the programmer way.

The Programmer Way
The idea was to extract all calls of the functions from wsc32.dll into a separate communication user object and to make uo_bc_print interact with a printer via that communication object. Then I could create a mock-up object with the same interface; for uo_bc_print it would look as if it communicated with the printer, but the mock-up object would not do it and would not use wsc32.dll. Then it would be possible at runtime to replace the communication object with the mock-up object.

The simplified structure of the new objects and their relation is shown in Figure 3. The u_nv_bc_comport_impl object contains calls of the external functions from wsc32.dll; in fact, all its functions simply redirect the calls to the external function. The u_nv_bc_comport_mock object does not call the functions from wsc32.dll. Initially I thought I would leave the function empty and not have a separate object at all and just use either u_nv_bc_comport_impl or u_nv_bc_comport. Then I decided that it would be nice to have a debug window that would display the strings that were sent to the printer. The functions of u_nv_bc_comport_mock do exactly this. The uo_bc_print object has an instance variable iuo_comport of the u_nv_bc_comport type. The idea was that soon after the creation of uo_bc_print, it would read the configuration setting, for example, from the Windows Registry, saying whether to use a barcode printer or emulate interaction with it. If a printer was to be used, uo_bc_print would create an instance of u_nv_bc_comport_impl and place the reference to it into iuo_comport. If a printer was to be emulated, uo_bc_print would create an instance of u_nv_bc_comport_mock and place the reference to it into iuo_comport. I placed the code that created a needed object into the uo_bc_print Constructor event script:

string ls_value
registryGet( '<my key>', 'emulate', ls_value )
if ls_value = '1' then
    iuo_comport = create u_nv_bc_comport_mock
else
    iuo_comport = create u_nv_bc_comport_impl
end if

All calls of the function from wsc32.dll inside uo_bc_print were replaced with calls of the corresponding functions of iuo_comport. As a result, only u_nv_bc_comport_impl was dependent on wsc32.dll. I could now use uo_bc_print without any problems during development without a barcode printer (along with u_nv_bc_comport_mock) and in production with a barcode printer (along with u_nv_bc_comport_impl). Nice job!