In previous articles, I discussed interfaces both conceptually and practically. So, we've discussed what interfaces are and how to use them in VBA. Now, let's talk about when to use them by going through a few scenarios where interfaces make sense. I'll cover the final scenario in this article.
- Backward-compatible refactoring
- Generic forms in a code library
- Dependency injection
- Cleaner IntelliSense
The Benefits of IntelliSense
I am an IntelliSense junkie. I think it's awesome. And I think my obsessive reliance on it makes me a better programmer. Allow me to explain.
My fingers are conditioned to type about three characters of an identifier and then press [Ctl] + [Spacebar] to auto-complete the identifier or bring up the auto-complete list if there happen to be multiple matches. I'm a touch typist and I'm reasonably fast, but any time I can save keystrokes I'm saving time.
If I'm typing a word and the last two letters are typed by each of my hands, I have a tendency to transpose the letters. But if I never have to type those last two letters because the IDE auto-completed it for me, then the mistake doesn't happen.
What did I name that class method? Was it .UserExists() or .LoginExists()? I could go to the class module and scroll through looking for the answer. Or I could just type the object instance name, add a period, then scroll through the list of properties and methods. That sounds easier; I'll do that:
Better coding through laziness
I may know I'm supposed to use constants instead of string literals in my code, but we all cheat on that sometimes. It seems like extra work, doesn't it? But I can't take advantage of auto-complete with string literals. However, if I assign my string literal to a constant, I can use auto-complete every time I refer to the constant. Path of least resistance for the win!
One of the best ways to improve your efficiency as a programmer is to be constantly aware of the signal-to-noise ratio in every aspect of your software development process. For example, if you over-comment your code then the most important comments (the signal) will get lost in your sea of useless comments (the noise).
Another example of this is in the auto-complete dropdown box. If your object has lots of properties and methods that you don't care about (the noise), then it will take longer than necessary to find the methods you want (the signal).
Progress meters revisited
In an earlier article, I wrote about a ProgressMeters form that I wrote and then refactored using interfaces. Here's what the auto-complete looked like BEFORE I switched to using interfaces:
All of those
After* event properties make me think of the auto-complete list for the Macbook Wheel:
Once I switched from referencing the form directly and instead declared the object variable's type to be that of my interface, the auto-complete list shrank considerably: