Java Inheritance Problem

Question

I have the finance application where we can have different types of transactions, like balance enquiry, funds transfer, and pin change etc. Now the Transaction is a base class, and there are specific child classes implementing it as per above use cases.

Class Transaction
{
    int txnId;
    String sourceAccountNumber;
}
Class PinChange extends Transaction
{
    int pin;
}
Class FundsTransfer extends Transaction
{
    int amount;
    String destAccountNumber;
}

Now I have a BankService object which takes transaction and executes it.

Class BankService
{
    executeTransaction(Transaction transaction)
}

I want to know:

1. How will BankService knows what is the type of transaction? Do I need to wrap it up in a new Enum like TransactionType and put it in transaction base class?

2. When the BankService comes to know type of transaction, how will it access specific class details? I think it needs to type cast transaction to specific child class, which seems bad to me. Thoughts?

Answer 1

If you have execute() method overridden in each child class, you can just call transaction.execute() inside executeTransaction(), so BankService does not have to know the transaction type.

However, I don't see the necessity of using inheritance here --- you can just have fundsTransfer, pinChange,... methods inside BankService class and implement them separately:

Class BankService
{
    executeFundsTransfer(BankAccount source, BankAccount target, int amount);
    executePinChange(BankAccount source, int pin);
}

Update:

You can have TransactionType enum class and make it a member field in Transaction: DEPOSIT, and WITHDRAW, but I don't think pin update or other methods are transactions, and they don't have a common (single) responsibility in executeTransAction method, so yes enum work but I don't see a strong reason that you have to use that.

Answer 2

You don't want BankService to know what the true type of the transaction parameter is.  It can find out by doing instanceof, but that is a red flag indicating OOP problems.

However, the transaction parameter variable knows what kind of object was passed in.

So, the idea is to tell the transaction object to do something for you, instead of inspecting it to see what to do.

The principle is called "Tell, don't Ask."

We don't have to use this approach, but using Ask instead of Tell is "contrary" to OOP.

Answer 3

There have been some good answers, but I would like to add to them.

1. Transaction is a terrible choice of base class name as it already has meaning, especially in financial and database-centric applications.
2. Model the real world. When I front up to an ATM I know that I want to deposit, withdraw or transfer between accounts. I don't think along the lines "let's do a transaction - what type?". So rather than inheritance the service you call should reflect reallity and have separate entry points for each operation. This will aid maintenance in the future. But full marks for asking. Hopefully the community can help improve your design.