Single Responsibility: a class takes care of itself and does its own actions.
You might do well to have canWithdraw methods...... Obviously your version will be slightly different.
Are you sure the storeMaximumID method belongs to the account class? Might it be a function of the bank class?
And, good idea to find out about SOLID but be aware that many people no longer believe the O bit.
Why do your setXXX methods return a BigDecimal?
Do you have any constraints about the values of those BigDecimals?
Why are you not doing any validation in the transaction constructor?
But how are you calculating interest on an account?
If the transaction is a withdrawal, that will represent the amount given to the customer. Just say, “amount of this transaction.”Tushar Goel wrote: . . .
Transaction class:
What you can do is have methods in the superclass like this and override them
with classes like Deposit and Withdrawal as subclasses.
That way the Account can maintain a List<Transaction>. There would be other ways to do it.
What about transactions for charges or interest?
You didn't really write == true, didyou
Decide whether the testAccountAvailable method throws the Exception from closed accounts or inactive accounts or what.
But I can't see any Exceptions in the set active method. Why are you using Booleans and compareTo?Tushar Goel wrote: . . .
It will throws exception for closed accounts.
. . .
But I can't see any Exceptions in the set active method.
Why are you using Booleans and compareTo?
prefer to see all fields initialised in the constructor
And what is wrong with
Junilu
First, the comment includes a description of logic that does not exist at all in the code.
a method that should probably be split into two methods.
As for the "rule" that involves account balances and "sufficiency", I would try to define an AccountRule, perhaps as an interface, like so:
Really? It is what you wrote earlier minus the == true bit. Well, as near as I could remember it, anyway.Tushar Goel wrote: . . . i could not able to think of this. . . .
I thought we had discussed reopening a closed account, in which case that method should throw an Exception.Junilu Lacar wrote: . . .
First, the comment includes a description of logic that does not exist at all in the code. . . .
If you use the bean pattern, however, activate and deactivate methods would not fit. It would be setActivated(true) rather like setVisible rather than show and hide.
Second, passing in a boolean parameter is a code smell that indicates a method that should probably be split into two methods. . . .
Campbell Ritchie wrote:If you use the bean pattern, however, activate and deactivate methods would not fit. It would be setActivated(true) rather like setVisible rather than show and hide.
Don't get me started about those stupid light bulbs. |