instanceof design question

[davidb09]

I am writing an basic accounts package which records money coming in/out of three accounts.
I have a basic 'Transaction' interface (java abstract class). Then depending on the account, I have 3 classes which implement the 'Transaction' interface: AccountOne, AccountTwo, AccountThree (not real account names)
Each transaction will be an instance of one of the account classes. I currently store all 'Transactions' in one single java 'ArrayList'.
To get a total of money going through an account type within a given month, I am currently iterating through the ArrayList, and using 'instanceOf' to determine the transaction type, to give a total for a specific account type.

Having read about the negatives of 'instanceOf', is there a better way to do this using e.g. polymorphism...
I cannot get my head around the problem...I'm hoping someone can suggest another way..????

 

[jmeckley]

Transaction would have a public member like GetTotal(). each concrete implementation would implement GetTotal();

Then cycling through the array you call GetTotal(); something like this (i'm a C# guy, so my syntax may be wrong.)

int total = 0;
ArrayList transactions = GetAllTransactions();
foreach(object transaction in transactions)
{
   total += ((Transaction)transaction).GetTotal();
}
return total;

Get total will have all the components necessary to calculate the total of the transaction.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190

 

[stevexff]

This doesn't sound right to me. Although it seems reasonable for accounts to implement the Transaction interface, this fails the is-a test. A transaction isn't an account, it's something you can do to an account. (It should probably be a class in its own right, so an account can list its transactions, and a transaction always has two accounts to enforce double-entry book-keeping, although this may be overkill for what you need). So your arraylist isn't a list of transactions at all, it's a list of accounts. Maybe it's just the nomenclature - if we called it the TransactableAccount interface it might be clearer?

But realistically, will there ever be a type of account that doesn't support transactions? Maybe you can move the interface methods up to an abstract base class for Account? It makes more sense to a casual reader of your code for Account to support getTotal() than it does for it to be treated as a Transaction.

To paraphrase Ward Cunningham, you know you are reading good code when each class and method does pretty much what you'd expect it to...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[jmeckley]

I agree with Steve. While your original question was not about how to structure your objects. It would make more sense to separate the concepts of Account and Transaction.

Jason Meckley
Programmer
Specialty Bakers, Inc.

faq855-7190

 

[davidb09]

I have changed the structure of the program as you say. This also makes it easier to get totals for individual accounts as each account now has its own array of transactions.

Thanks both for the help!