👋Learning to code? Check out ourbrand new Bootcampfor beginners!
After years of filling out forms and waiting, you've finally acquired your banking license. This means you are now officially eligible to open your own bank, hurray!
Your first priority is to get the IT systems up and running. After a day of hard work, you can already open and close accounts, as well as handle withdrawals and deposits.
Since you couldn't be bothered writing tests, you invite some friends to help test the system. However, after just five minutes, one of your friends claims they've lost money! While you're confident your code is bug-free, you start looking through the logs to investigate.
Ah yes, just as you suspected, your friend is at fault! They shared their test credentials with another friend, and together they conspired to make deposits and withdrawals from the same account in parallel. Who would do such a thing?
While you argue that it's physically impossible for someone to access their account in parallel, your friend smugly notifies you that the banking rules require you to support this. Thus, no parallel banking support, no go-live signal. Sighing, you create a mental note to work on this tomorrow. This will set your launch date back at least one more day, but well...
Your task is to implement bank accounts supporting opening/closing, withdrawals, and deposits of money.
As bank accounts can be accessed in many different ways (internet, mobile phones, automatic charges), your bank software must allow accounts to be safely accessed from multiple threads/processes (terminology depends on your programming language) in parallel. For example, there may be many deposits and withdrawals occurring in parallel; you need to ensure there is no race conditions between when you read the account balance and set the new balance.
It should be possible to close an account; operations against a closed account must fail.
An account can be opened.
On opening, its initial balance should not be negative.
If a negative balance is given to the Open function, nil must be returned, otherwise the newly created account must be returned.
An account can be closed.
When closing an account, the Close method must return the balance the account has and a boolean true indicating the account was closed successfully.
Closing an account does not succeed if the account is already closed.
When an account is closed, its balance must be set to 0.
The Balance method allows a user to check the current balance of an account.
It must return the balance of the account and a boolean indicating if the operation succeeded.
Checking the balance only doesn't succeed if the account is closed.
Deposits and withdrawals are both handled by the Deposit method.
If the argument given to the method is a positive amount, then that amount of money must be deposited in the account.
If the amount given is negative, that amount of money must be withdrawn from the account.
If the account is closed, its balance must not be modified.
Deposit returns the new balance of the account and a boolean that indicates if the operation succeeded.
Deposit must fail if the account is closed or if there is not enough money to withdraw from the account.
The tests will execute some operations concurrently. You should strive to ensure that operations on the Account leave it in a consistent state. For example: multiple goroutines may be depositing and withdrawing money simultaneously, two withdrawals occurring concurrently should not be able to bring the balance into the negative.
When working locally, you can test that your code handles concurrency properly and does not introduce data races, run tests with -race flag on.
$ cd exercism/project/directory/go/bank-account
$ go test -race
If you are new to concurrent operations in Go it will be worth looking at the sync package, specifically Mutexes:
Edit via GitHub
Sign up to Exercism to learn and master Go with 34 concepts, 141 exercises, and real human mentoring, all for free.