The post is very interesting in that it does a good job summarizing points that I have seen made elsewhere with regards to difficulty in inserting mock objects into existing code. From what I have seen so far, it appears that the problem lies not in lack of features in the languages used, but rather ineffectual use of abstraction in code.

To try and paraphrase the example is essentially that given the following code :

class Account
{
	private balance = 0;
	private log = new TransactionLog();
	
	deposit(value) {
		log.addEntry(balance, value);
		balance += value;
	}
	...
}

class Account
{
	private balance = 0;
	private log = new MockTransactionLog();
	
	deposit(value) {
		log.addEntry(balance, value);
		balance += value;
	}
	...
}

For me this is a perfect example of why abstraction is useful at the implementation level and it ties in with my previous blog entries (OOP Case Study: A Bank Account class Part 1 and Part 2) about how an Account class should be built from the group up using different layers of abstraction.

Here we have an Account class which is overloaded with responsibility, it is the lowest level of representation of the Account, but it also carries the responsibility of commiting all deposits to a log. The purpose of abstraction is to separate responsibilities into different layers of abstraction. The account class would have been much better off if it was written as two classes and one interface:

class RawAccount 
{
  private balance = 0;
  deposit(value) {
    balance += value; 
  }
  ...
} 

class TransactionalAccount
{
  RawAccount acc;
  private log = new TransactionLog();	
  deposit(value) {
    log.addEntry(balance, value);
    acc.deposit(value);
  }
  ...
}

interface IAccount {
  deposit(value);
  ...
}

In order to have a mock object it would be easy and logical to add a template parameter to TransactionAccount which provides the concrete type of the transaction log:

class TransactionalAccount<class LogType>
{
  RawAccount acc;
  private log = new LogType();	 
  deposit(value) {
    log.addEntry(balance, value);
    acc.deposit(value);
  }
  ...
}

class TransactionalAccount<class LogType>

interface ILog
{
}
 
class Account : IAccount
{
    Account( ILog log );
}
 
//...
 
IAccount testAccount = new TestAccount( new MockLog() );
IAccount realAccount = new TransAccount( new TransactionalLog() );

IAccount testAccount = new TestAccount( new MockLog() );
IAccount realAccount = new TransAccount( new TransactionalLog() );

IAccount testAccount = new TransAccount( new MockLog() );
IAccount realAccount = new TransAccount( new
TransactionalLog() );

IAccount testAccount = new
> TransAccount( new MockLog() );
> IAccount realAccount = new TransAccount( new
> TransactionalLog() );

class Account
{
    private int balance = 0;
    private Log log;
 
    Account(Log newLog)
    {
        this.log = newLog;
    }
 
    deposit(value) 
    {
        log.addEntry(balance, value);
        balance += value;
    }
	...
}
 
interface Log
{
    void addEntry(int b, int v);
}
 
class TransactionLog implements Log
{
    :
}
 
class MockLog implements Log
{
    :
}

class TransactionLog{
   public TransactionLog()
   {
      // if (system.property == "test") do nothing
      // else
      //    do the usual things.
   }
   ....
}

class TransactionLog{
   public TransactionLog(boolean testing){
      if (! testing)
        // do usual thing 
      else
        // do nothing
        
   }
   ...
}
[\java]
 
This option of changing the TransactionLog constructor does require changing the Account class too. Furthermore, changing the TransactionLog constructor will affect other classes that use TransactionLog. Assuming that the Account class/interface was designed properly, I would like to cause as little change to the Account class as possible. 
 
The System Property method is less intrusive, requiring change only at one place, and the general idea is applicable to other situations. 
 
Note that using the system method is akin to using AOP (almost, but not quite).