It means that once you have an overridden equals method you should not add any fields in subclasses.
you cannot regain symmetrical behaviour in the equals method without breaching the Liskov Substitution Principle.
Did you manage to create an instance by passing null for name?
Don't catch unchecked Exceptions in production code
There are all sorts of weird and wonderful names around.
you will find out how to get a non‑empty name.
No, it was the mistake I made about six months ago. Prasanna Raman found it.
And what is wrong with double validation?
… you get an empty String from nextInt() × 3 nextLine()123 456 789
Campbell
You may have to wait one line before you start printing error messages.
No, the nextInt method and next line do not skip the next line. The nextLine method reads the remainder of the current line. If you have input likeTushar Goel wrote: . . .
Yeah if i take int first and then try to read using nextLine() then it will skip that line. As this problem comes only when we are reading after nextXXX() so i already
solve this in my getInt() method. So i can call now use userInput() method safely.
… then reading with your method will find 123 and discard 456 789.123 456 789
Campbell
AgreeTushar Goel wrote: . . .
1) Each account has unique account number.
Are you sure this is necessary at this stage? Probably right however.2) Account status can be Active , Inactive or Closed.
How do you know there will be three types?3) Account can be of Saving, Current or Salary type .
Why are you specifying that sort of thing at this stage? Even if there are minima, they will change from time to time. So will interest rates and charges.4) Minimum amount require to open an account. . . .
Agree.. . .
13) Once account is closed it can not be re-open. . . .
Why only whole numbers of dollars?
An empty account would be empty not inactive. You may close an empty account but it is only inactive if there has been no activity for a long time.
Why are you rounding in the account? Any rounding should be done before anything gets anywhere near the account.
.... Why we are not defining other things like minimum amount require to open , minimum balance required, interest and penalty
now, i understand they keep changing and can not be hard coded but then how we pass there value later and where we define them? .....
What i am thinking, right now after making changes as you suggested we are defining basic version and later as per specific requirement we will extend this class and
add features as required? Is it correct?
I was thinking of an over the counter withdrawal: again it would be in $ and ¢Tushar Goel wrote: . . . I was considering withdraw through ATM only so i forgot to think the case of online transfer...
Yes. Any amounts in or out should be rounded two 2dp before they get anywhere near the Account object.. . . You mean before amount is added into the balance.
Is a minimum amount an essential feature of an account? If it is, then code a minimum balance field in the superclass and set it to zero. Give any methods to set that amount appropriate access and rules for setting it. You can regard a negative minimum as a permitted overdraft.
.... Why we are not defining other things like minimum amount require to open , minimum balance required, interest and penalty
. . .
Is a minimum amount an essential feature of an account?
You can regard a negative minimum as a permitted overdraft.
Similarly interest and penalties could be superclass fields. Set them to zero too
Yes, but hard-coding zero is less serious.Tushar Goel wrote: . . .
Ok, thanks but is not this hard coded again?
. That would suggest you can withdraw and deposit in the same transaction.
Why are you passing an account to that method?
he idea is to make you think about it and query all your decisions; that way you will improve all your decisions.
Did you see how Paul cut 87% off of his electric heat bill with 82 watts of micro heaters? |