On 8/12/2015 8:42 AM, Wilson, Jonathan wrote:
I am curious as to how others have dealt with this problem or done
something similar, or if prevented by just not doing multi-format data
passing.
In my experience, this architecture comes about from a desire to keep
related I/O together. I won't editorialise on that, but I bring it up
to note that it's not that difficult to write smaller procedures which
are exposed to callers while the inner, I/O procedure is kept hidden
from them.
In your example you might write
GetBibliographicDataFirstKeys();
GetBibliographicDataFirstFmt001();
GetBibliographicDataFirstFmt002();
...and each of these would call the internal GetBibliographicData() with
the appropriate parameters. The benefit to this arrangement is that the
exported procedures (the detailed ones) each have one and only one
parameter list, and it's a pretty firm contract between the caller and
the callee.
The argument can be made that it's now 4 subprocedures instead of 1, and
while that's true, each public subprocedure does one well defined task,
handling the details of the messy I/O rather than forcing each caller to
understand how to do it. If those details ever (!) change, the messy
I/O can be dealt with on a few, easy to find places and none of the
callers need know that the rewrite happened.
As an Amazon Associate we earn from qualifying purchases.