Note: there are no deeper insights in this article – just some rambling.
I have a confession to make. I never really understood DLLs. They were some sort of software blackbox for me, something that dawdles about in the install folders of proper software products, like minions waiting to be summoned. I knew that they contain executable code. But the stench of “unnecessary complexity” always kept me from actually looking up how they work and what they are good for.
I’m currently working on a Feedly/RSS client for Windows Phone. One of the features I wanted to implement was periodic background refreshing, so you don’t have to wait for the app to first refresh everything before you can read your rss feeds.
But having to start the full app in the background every time there’s a refresh supposed to happen would be way too expensive. So the background services are actually tiny additional executables that can only use a specific quota of memory, bandwidth and cpu time, or the system will immediately kill them. It works surprisingly well.
Anyway. So now my project consists of two executables, the big app and the tiny background service. The background service is supposed to do the same thing that happens when somebody taps the “refresh” button in the app. I could just have copy-pasted that function into the background service. Except for that I really, really didn’t want to do that. Because, see, I have two rules that I stick to:
1. Do it properly.
2. Avoid redundancy.
Having the same piece of code in two different places in the same project is an invitation for tragedy. Sooner or later, you WILL change the one copy and forget to update the other copy. Never go down that rabbit hole.
I did some experimenting with hotlinking a sourcecode file from both executables – terrible idea, doesn’t even work. So I finally bit the bullet and looked into DLLs. And it turns out that DLLs are the perfect tool for solving this problem. I put my code in the DLL. I make both executables call this DLL. It’s the clean and simple way, and it wasn’t hard to learn.
Still, I don’t feel bad for not having looked into it sooner. Sometimes it’s hard to tell when the right time is to learn a new thing – it could always turn out to be overly complicated or a waste of time. There are so many technologies out there that are still in use despite being obsolete, simply because people are used to it.
Learning is an investment of time. How long will it take to whip up a working prototype – ten minutes, an hour, a few days? Will you be using your new tool often enough to ever see a return of investment? It’s a dilemma.
There is a solution, though. Just code until you drop – the more you program, the higher the chances of coming across good usecases for all the obscure stuff.