The object-oriented bank account example is a common demonstration of OOP by attempting to model a bank account class. Eric Theriault referenced a talk on his blog by Kevlin Henney which brought the old chestnut to the forefront of my consciousness again. Here is the quote from Eric's blog which I find rather enlightened.

... one of my courses at OOPSLA has been with Kevlin Henney, and he reminds us that when developing object oriented software, the getters and setters are generally not the proper abstraction for an object. More specifically, his example was for a Bank Account, where the methods provided are getBalance() and setBalance(). While this is a very powerful interface, this is not the proper abstraction to use, especially since in this case, the object could change state between the initial get and the final set. As such, a better interface would be a method to acquire the current balance, a method to withdraw funds, and a method to deposit funds. In addition to being a more coherent interface, the business logic can easily be applied in this design.

There is no argument from me that Get and Set is a naive interface to a multi-threaded bank account class. It is pretty safe to expect that a bank account class is going to be multi-threaded, as most models of a transactional system probably should be.

The issue is, if we only provided locksafe Deposit / Withdraw, how do we deal with something like deposit interest? We could conceivably provide another function for DepositInterest. The next problem would be a bank fee scheme which depends on the amount of money in the account. Again this also has to be thread safe. But what happens is we are overloading the repsonsibility of the account class.

What makes the most sense is to keep the BankAccount class as simple as possible. Something like: ViewBalance, GetBalanceAndLock, SetBalanceAndUnlock. Strictly speaking nothing else is needed, all other functionality can be provided from that basis. More sophisticated functionality can be implemented in very simple account accessor classes. Withdraw and Deposit for instance chould be separated into a new class which could be descirbed as below:

TellerAccountAccessor {
  PayBill(amount) {
    cur = account.GetBalanceAndLock()
    account.SetBalanceAndUnlock(cur - amount);
  }
  Withdraw(amount) {
    cur = account.GetBalanceAndLock()
    account.SetBalanceAndUnlock(cur - amount);
  }
  Deposit(amount) {
    cur = account.GetBalanceAndLock()
    account.SetBalanceAndUnlock(cur + amount);
  }
  BankAccount account;
}

Since I brought up the concerns of interest and fees it would make sense to have another class which provides that functionality:

BankAccountAccessor {
  DeductFees(exemption, fees) {
    cur = account.GetBalanceAndLock();
    if (cur < exemption) {
      cur = cur - fees;
    }
    SetBalanceAndUnlock(cur);
  }
  DepositInterest(interest_rate) {
    cur = account.GetBalanceAndLock();
    interest = cur * interest_rate;      
    cur = cur + interest;
    SetBalanceAndUnlock(cur);
  }
  BankAccount account;
}

I invite the reader to share their thoughts on the subject. Even the simplest of basic object oriented designs can make for interesting and informative discussion.

interface Transaction {
  public Object execute(Connection conn);
}
 
class DatabaseUtils {
  public static Object doTransaction(Transaction t) {
    Connection conn = null;
    try {
      conn = openConnection();
      return t.execute(conn);
    }
    finally {
      conn.close();
    }
  }
}

interface RawAccount {
  ViewBalance() : Double;
  SetBalance(Double amount); 
}

interface RawAccount {
  ViewBalance() : Double;
  Withdraw(Double amount);
  Deposit(Double amount);
}

interface LockableAccount {
  ViewBalance() : Double;
  GetBalanceAndLock() : Double;
  SetBalanceAndUnlock(Double amount); 
}

interface TransactionableAccount {
  ExecuteTransaction(Transaction t);      
}

interface IRawAccount {
  public {
    int GetBalance();
    void SetBalance(int amount);
  }
}
 
interface ILockableAccount extends IRawAccount{
  public {
    void Lock();
    void Unlock();
  }
}
 
interface IAccount {
  public {
    bool ExecuteTransaction(ITransaction);
    ITransactionLog GetLog();
    int GetBalanceAsOf(DateTime date);
    int GetBalanceNow();
  }
  // note: an implementation would likely use
  // a class implementing ILockableAccount
}
 
interface IAccountConnection
extends IRawAccount {
  public {
    IAccount GetAccount();
    bool IsValid();
    void Invalidate();
  }
}
 
interface ITransaction {
  public {
    bool Execute(IAccountConnection);
    IAccount GetAccount();
    DateTime DateTimeExecuted();
    bool ExecutionSuccess();
    String TransactionCode();
    int OldBalance();
    int NewBalance();
  }
}
 
interface ITransactionLog
extends IArray<ITransaction> {
  public {
    void AddTransaction(ITransaction);
  }
}
 
interface IWithdrawal
extends ITransaction { }
 
interace IDeposit
extends ITransaction { }
 
interface IBillPayment
extends ITransaction { }
 
interface IInterestDeposit
extends ITransaction { }
 
interface IDeductCharges
extends ITransaction { }
 
interface IBalanceAdjustment
extends ITransaction { }
 
interface ITeller {
  public {
    bool Withdraw(int amount);
    void Deposit(int amount);
    bool PayBill(int amount);
  }
}