Mostly. The problem is that I'm trying to do a better job of organizing the secret knowledge about our product so that things become easier to maintain. As part of this, I've written a new class for this particular operation to collect the data that I need. The server will put the data into the class, I'll modify it in our admin app, then I'll pass the data back to the server to store the changes.
Now I'm of the opinion that good design calls for a class to know how to retrieve and store its own data. I'm also of the opinion that shared classes belong in a shared DLL instead of being compiled into each application with conditionally compiled code to handle the fact that, say, the admin app is going to send the data to the server to be stored, while the server is just going to read and write the data from the underlying data storage.
Um, oops. Yes, that's a problem. Not only does the class do different things to load and store data depending on whether it's located on the admin side or the server side, but the code to support those different methods of storage isn't shared and probably shouldn't be shared. There's no particular reason that the admin app should know how to locate and write a server-side data storage; nor is there any reason that the server should know how to talk to itself. (Well, unless we had different servers talking to each other, but that's a whole different can of worms.)
Fortunately, I have a solution for this problem. (You sort of guessed that by now, didn't you?) I implement a class in the shared DLL that contains my data class. That class provides static methods -- that is, a function name that I can safely call from anywhere -- for reading and writing my data class. Those static methods use a static pointer to a class derived from the class with the static methods to call virtual functions that could actually do something, if only that something were defined somewhere.
(A virtual function in C++ is a function that can be replaced by a different function that's defined in classes that are derived from the base class so that it does something different than the base class defined. And I'm about to take advantage of that.)
So now I can derive two new classes from the base class that contains the static methods. One of them goes into the server side, the other into the admin side. The server and the admin applications are separate executable files, so I can instantiate exactly one of these derived classes in each executable. Through a simple bit of programming, the base class gets the pointer to the derived class and uses it to call the virtual functions there.
And the function on the server side knows how to read and write my data class on the server, while the function on the admin side knows how to read and write my data class there. So I just add two functions to the data class, Load() and Save(), and tell them to call the static methods that I defined in the base class, and the base class calls the virtual functions in the derived classes to load and save my data class.
Which is what I wanted to have happen. (Or, at least, it will happen once the other programmer fills in the necessary server communication code in those virtual functions.)
The net result of all this machination is that I can ask my data class to load itself and save itself and the right thing will happen, no matter where the class is sitting, in the admin app or on the server.
Sadly, the other programmer who is supposed to be writing the code to make the load and save happen does not particularly like this solution, despite the fact that I've written all of the boilerplate so that all he has to do is fill in the blanks. (Blanks which have not been made any harder for him to code by my saying to him, "Put your code here.")
However, it looks like he's going to code it to my specification. At least mostly.
And that will be good.
I should be able to reuse this approach to solve several vexing problems that we have with the current code base, so it's worth getting the concept into play, demonstrated as working, and -- I hope! -- eventually accepted by the other programmers in the group.
Either that, or they're going to have to come up with a better approach that actually works.
And if they do, I'll be happy to see it. :)