0

I am creating a bank software system.

In this system, there are 3 account types: Savings, Checking, CD.

Each account from any type has an ID, apr, and amount, and we can withdraw from it.

So I can have an abstract class Account, that contains ID, apr, amount variables, and withdraw(int amount) method.

But, we can deposit only in Savings and Checking accounts, and we can transfer money only between Savings and Checking accounts.

So the 2 methods deposit(int amount) and transfer(id, amount) can not be defined in the Account abstract class.

I am thinking about making an interface nonCDAccount, that contains 2 methods: deposit() and transfer(), and implementing that interface from Savings and Checking classes.

Is it a good idea? If not, what should I do?

Improve this question
7
  • 1
    There is indeed a better model than what you have described. Thought experiment: What happens to the money if the transfer between two accounts fails after a withdrawal from one and before it is deposited into the other? Is there a better way to model the transfer?
    – Kain0_0
    Commented Apr 23, 2021 at 0:23
  • Actually, system requirements do not take care of the case you have mentioned, this system is just a simulation, so you can suppose that withdraw then deposit methods will be executed sequentially and successfully.
    – X Y
    Commented Apr 23, 2021 at 4:14
  • ?? A bank that doesn't care where the money goes to or comes from? Are your sure you are modelling a bank? I've worked for them in the past, they take this sort of thing very seriously. Even as a simulation this is an awkward way to simulate.
    – Kain0_0
    Commented Apr 23, 2021 at 5:06
  • Yes, it is a very simple simulation, and the case that you have mentioned (withdraw succeeds but deposit fails) is not listed in the requirements.
    – X Y
    Commented Apr 23, 2021 at 6:14
  • 2
    It's surprising how often a "banking system" features as the target of those attempting a basic OO model, and yet the basic things that exist in a banking system, like a journal, make no appearance at all. At it's very simplest, a deposit of cash doesn't just lead to your account being credited, but also to the bank's "cash drawer" account being debited simultaneously as part of a single transaction.
    – Steve
    Commented Apr 23, 2021 at 8:51

2 Answers 2

Reset to default
1

Your solution of an abstract Account class and an interface for the the nonCD accounts should work.

But it depends how you intend to use the class and the interface in your API. Do you for example assume that every time you have a nonCD, it’s necessarily an account? If yes, two alternatives are possible:

  • You could make nonCD an abstract class that extends Account. This works well if the type of account is defined at construction and is not supposed to change.
  • You could use the decorator pattern where nonCD would extend the responsibilities of Account. This works well if responsibilities of the account would change during its lifetime, and might be over-engineering in your case.

Not related: The comments suggest that you are not in banking software but more in learning by simulating banking. This is why I’d like to question your understanding of the requirements. I’ve understood that a CD account is a deposit-only account. There is no withdrawal on it: withdrawal of money means to close that account. But perhaps these accounts work differently in the simulation world you're working on, and it’s OK for your exercise. So cross-check it before starting to build on the wrong assumptions.

Improve this answer
2
  • Yes, I am working on an educational project (not a real one), where the requirements are predefined. The requirements assume that you can not deposit in a CD account, and you can withdraw only the entire balance after 12 months have passed. I have another question, which is better in the transfer method, sending the account's object that I need to transfer to, or sending its ID and searching for the object inside the transfer method (depending on the ID)?
    – X Y
    Commented Apr 23, 2021 at 19:18
  • 1
    @XY Technically, both are feasible. The advantage with an account object is that you are sure that there is such an account. However, this assumes that the target account is managed in the same bank and on the same system. This is ok for a simulation, but in real world, you’d probably use an ID for searching in an account repository : this offers more flexibility and allows for scalability (e.g. message passing between different services, no need to have all the accounts involved loaded at once, etc).
    – Christophe
    Commented Apr 23, 2021 at 20:18
-1

You can have methods canDeposit and canWithdraw in your interface. This makes it possible for your ui to adapt, like not showing a window for entering a deposit amount when you can’t deposit.

And you can have methods deposit() and withdraw() which assert when you call them when the call isn’t allowed (because that’s a programming error) and do the right thing otherwise.

And you can shoot drive-by down voters who don’t actually have any really arguments that they could put into a comment.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.