Ryan Shriver
Posts: 9
Nickname: rshriver
Registered: Oct, 2002
|
|
Re: OOP Case Study: The Bank Account Class
|
Posted: Nov 10, 2004 9:34 PM
|
|
I've enjoyed the discussions for this thread and agree that we've gone well beyond the original scope. I'm the architect (and developer!) for my client and we're in the midst of developing a Java based accounting system for Loans and Leases. It's a product developed for banks and captive finance companies. After a year on the job I'm learning more than I ever could imagine about how accounting systems work. I mention this not try and impress anyone but to give you my frame of reference. Hope you don't consider this overboard :-)
Some observations from my experience:
1. There's no such thing as a 'simple' bank account example, so this really is a hard problem to try and make simple :-) There's subtleties in ever corner.
2. Locking the account while doing things isn't really the issue, I don't believe. Databases support atomic updates. Processing transactions against accounts and recording their effects is the central issue.
3. The single hardest problem in developing banking systems is dealing with the effect of time on money. It's a tricky problem. What happens when a check falls behind someone's desk, three months pass, and they need to post it effective three months ago? Or you need to reverse an expense because the customer complains and the manager agrees? In the real world things don't always go right the first time and sometimes we need to 'correct' history after the fact.
To do this requires you to be able to recreate the snapshot of the account at a specific point in time, apply the right transaction, and then apply all subsequent transactions back against the account to bring it up to date. Then persist the changes in a database transaction on commit, else rollback the transactions affect on the account. The event model where each one creates one or more related transactions greatly simplifies this capability. Especially if the transactions are linked, because reversing parent transactions typically reverse all their children.
This is one model, there are others.
Here's a simplified Transaction interface:
public interface Transaction {
public String type();
public Money amount();
public Date effectiveDate();
public boolean isParent();
public boolean isChild();
public boolean isReversal();
public Transaction parentTransaction();
public List childTransactions();
public List accountingEntries();
public List debits();
public List credits();
public Transaction reverse();
public boolean execute();
}
Then we get into different types of Transactions:
public class Payment implements Transaction {}
public class Adjustment implements Transaction {}
public class Fee implements Transaction {}
public class Expense implements Transaction {}
public class LateCharge extends Expense{}
public class Withdrawl implements Transaction {}
public class Deposit implements Transaction {}
Where each has their rules within execute(); Doing this allows you to treat all these generically as Transactions but allow each to contain different rules.
Then you can add methods to your BankAccount class like this:
public class BankAccount {
private Money principle;
private Interest interest;
private TransactionHistory history; // collection of Transactions
// applys payment to account, returns current balance
public Money applyPayment(Payment payment) {
payment.execute(); // payment posting rules encapsulated, they update the accounts fields and adds to the trans history
return principle.plus(interest);
}
// other operations might include
public Payoff quotePayoff(Date forDate) {}
public Money withdraw(Money requestAmount) {}
public Money deposit(Deposit amount) {}
}
Accounting systems must also support double entry accounting in the form of debits and credits to the general ledger in addition to maintaining balances, applying payments, etc. That's your 'on the record' books of things that gets audited by Auditors in suits. That can be saved for another thread!
-ryan
P. S. Martin Fowler has written extensively on principles of accounting systems and his work has guided me throughout this project. Check out his web site (www.martinfowler.com) for some great references. He proposes an Event based system where Events create one or more Transactions that are related. This model has been effective for us.
|
|
Previous Topic
