Have you ever been having a dream, that sometimes you would like to get rid of all specific input arguments in your function interface?
I mean, instead of this:
Public Function calc(Byval a1 As Double, Byval a2 As Double, ... , Byval n As Double) As Double
you could have this:
Public Function calc(Byref parameters As someDataStructure) As Double
Keep on dreaming, you got company here. I would like to share one approach what I have been using for some time.
Let us say, that we are going to use VBA Interface mechanism in our program. Let us also think, that our public interface is having only one public function to be implemented. In this case, we need to have homogenous public function interface for all implementations created from it. But what happens, if I would like use different set of input parameters for each interface function implementation?
One solution for this problem is to wrap all your specific input parameters inside some data structure, like Trojan horse. Then, instead of having n specific input arguments defined in your public function interface, you just have one data structure as your single input argument. The upside of this approach is, that there can be any number of specific parameters inside that data structure.
This approach does not necessarily make your life easier, but more importantly it can enable these (IMHO) more flexible program designs. Note: at this point, you should be well familiar with VBA Enumerators and Microsoft Scripting Runtime library’s Dictionary object. If you feel unsure with these or you need some brush-up, there is a lot of information to be found in Google.
The following program calculates a price for simple non-cashflow paying forward, by using conventional VBA approach by giving all specific parameters separately in a function interface:
There is absolutely nothing wrong with this approach. But, just for the curious .. how could you get rid of these three parameters we are using in that function interface? Just put everything inside Dictionary data structure. We can define distinct Key-Value pairs inside Dictionary object. In our example case, the Key is Enumerator value (spot, rate, maturity) and the Value is a double (100, 0.02, 1.25). For using this approach, we need to have a separate Enumerator data structure for all possible Keys what we would like to use in our parameter wrapper. Just for our example case, Enumerator would look like this:
The following program calculates a price for simple non-cashflow paying forward, by using that data structure approach by giving all three specific parameters wrapped inside data structure in a function interface:
Now, what if we need to have more than these three input parameters for some specific implementation? First we need to add more "Keys" to our enumerator. Then we just wrap all our specific parameters into a new Scripting.Dictionary object.
So, that was all I wanted to show about this issue. Personally, I find this approach to be extremely flexible for designs where I would like to use VBA interfaces. The downside is, that you need to have that Enumerator data structure and it needs some babysitting. This Enumerator is a public one and also shared by all modules and classes in your program. Some programmers and authors could definitely find this to be a clear sign of sorcery. For me, it is a price I need to pay to have that flexibility. Also, if you look at the forwardPrice function above, you can see that "disassembling" parameter values from Dictionary object back to program-level is a bit more complicated, than using just plain old separate parameter approach.
I hope, that you got yourself at least some new ideas for your programs. Good luck!