Return to Revisions

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.