|
When Jeff asked this question my mind shifted to a program I wrote some years ago, and is currently used by tellers in process sing over-the-counter transactions at 250+ credit unions in the US. A transaction begins simply enough by prompting the teller for: Member Number Account Suffix Transaction Code Amount Description Operation Code Holy Cow, it would take a volume to describe the chain of events and conditions those six (6) simple fields trigger. Member Numbers uniquely identify credit union members, and properties delineating conditions they've requested to be associated with their accounts. Account Suffix identify types of accounts which fall into three (3) general classifications (shares, loans, and certificates of deposit), and sub-classifications (savings, checking, individual retirement arrangements, standard loans, credit card loans, etc.) Transaction Codes identify types of transactions such as Deposits, Withdrawals, Payments, Advances, Standard Debits and Credits, involving various types currency, checks, and other mediums of exchange. Transaction Amounts may be subject to dozens of conditions. Operation Codes refer to external table entries that further qualify transactions, and often lead to further prompts. For example an Operation Code may be set up for handling Traveler's Cheque sales, which need to record the number, denominations, and serial numbers of cheques sold. Teller user profiles themselves have numerous properties that affect program flow. Scanning the source code of this program, which is procedurally oriented, gives a glimpse at the number of conditions, tables, and possible extensions associated with every input field, which number in the hundreds. Thank you, Joe Pluta, for pointing out that the strengths of OO are actually weaknesses when it comes to handling procedures like this. I strongly agree with 90% of what you've written during the past several days. You've taken a lot of flack, and we're able to dish it back with remarkable agility and clarity, focusing on specific issues. Nathan Andelin
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.