You’re write the example I’ve given probably is a bit simplistic and certainly it would be possible to pass in the wrong account to the constructor. Nothing immediately comes to mind with respect to how we can avoid that though.

@anon – If I follow your example correctly then I guess the question would become where would the Transfer method be called from – it feels to me like it doesn’t really belong on either the DebitAccount or CreditAccount objects since it affects both of them?

Maybe it should go on a Transfer object which they can both interact with.

@Mark – nothing to stop you, you’re right! Can’t immediately think of a way to get around that.

Strict types sounds interesting – I wonder if the code contract stuff from Microsoft would be able to help us here – http://richardsbraindump.blogspot.com/2009/02/code-contracts.html

public void do(TransferMoney cmd) {…}

Like Carlo, my Account class would have a TransferTo(amount, targetAccount) method, thus removing the confusion.

The micro-types I *do* miss, in C# are the strict types you could create in Pascal and Ada. eg To define a type as being a limited range of numbers. Any thoughts on implementing this kind of thing?

[I haven't done any Smalltalk for a decade. Thanks for reminding me how cool it is, Carlo!]

public interface IAccount
{
// return the IAccount interface for method chaining
IAccount Transfer(IAccount creditAccount, decimal amount);
}

public class Account : IAccount
{
IAccount Transfer(IAccount creditAccount, decimal amount)
{
…
}

public static IAccount Load(int accountId)
{
…
}

}

IAccount debitAccount = Account.Load();
debitAccount.Transfer(Account.Load(), 100);

In Smalltalk (I’m a Java developer by trade though) I’d write something like:

debitAccount transfer: 25 dollars to: creditAccount.
Or
transaction:=AccountTransaction transfer: 25 dollars from: debitAccount to: creditAccount.
transaction transact.
transaction rollback.
OR best of both worlds
transaction:=debitAccount transfer: 25 dollars to: creditAccount.
transaction transact.
transaction rollback.

I guess this comes down to Rebecca Wirfs Brock’s Responsibility Driven Design and Ward Cunninghams Whole Value pattern (== Eric Evans Value Object); where should this behaviour sit and what best describes my intent.

Personally thats why I like Smalltalk, it’s all objects and messages; and has a higher potential to describe my intent.

Creating specific account types as you suggest has made the code more specialised and less general; Is it unreasonable to transfer money between any 2 accounts?
Thinking about this again I’d say the issue is variable naming as the micro-typing gives you a false sense of security as somewhere in the code you’d still need to make the decision to wrap each account to classify it as either debit or credit.

Obviously there are many more factors to be aware of in the designs above depending on what we’re asked to do.

Keep up the great blogging…