|
In programming utopia, the caller doesn't know or care about the procedure. Procedures are supposed to tend toward simpler, and when I find myself needing a structure, it's often because I didn't decompose the problem far enough.
On the other hand, there's a very good reason to use a structure rather than a few dozen calls to separate procedures: efficiency. Consider the case when your application is really an API that you've written. You want to get customer information from the database and send it out over the web. You write several dozen low level procedures that each return one bit of information (one does name, one does credit score, one does favourite colour, etc.)
Now you want to ship that all off to the web. Through nefarious means, you discover that it takes .3 seconds for each Java Toolbox program call (or ODBC dip, or...) By wrappering all 24 API calls into a single 'give me my customer info' API, you save half a minute in the response time of that particular web transaction. You call one API which runs on the iSeries and quick as a cat it calls all 24 low level APIs and bundles the results in a neat structure for your web-Java code to have fun with.
There are times I will trade utopian ideals for run time performance, but I always think of passing structures as a red flag, cautioning me to reconsider what I'm doing.
--buck
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
