Avatar of devcraftsman

devcraftsman's solution

to Bank Account in the Scala Track

Published at Aug 27 2019 · 0 comments
Instructions
Test suite
Solution

Simulate a bank account supporting opening/closing, withdrawals, and deposits of money. Watch out for concurrent transactions!

A bank account can be accessed in multiple ways. Clients can make deposits and withdrawals using the internet, mobile phones, etc. Shops can charge against the account.

Create an account that can be accessed from multiple threads/processes (terminology depends on your programming language).

It should be possible to close an account; operations against a closed account must fail.

Instructions

Run the test file, and fix each of the errors in turn. When you get the first test to pass, go to the first pending or skipped test, and make that pass as well. When all of the tests are passing, feel free to submit.

Remember that passing code is just the first step. The goal is to work towards a solution that is as readable and expressive as you can make it.

Have fun!

Hints

This exercise is testing mutable state that can be accessed saftely from multiple threads. Scala provides a variety of ways to protect mutable state. For developers familiar with Java concurrency, Scala can utilize the Java concurrency support such as the Java synchronized block.

Common Pitfalls

In Scala there are two ways to achieve mutable state: Use a "var" or a mutable object. Two common mistakes here are:

  • Do not use a "var" that is also a mutable object. One is enough, but not both together.
  • Don't expose the "var" or mutable object to the outside world. So make them "private" and change the mutable object into immutable before you return it as a value.

The Scala exercises assume an SBT project scheme. The exercise solution source should be placed within the exercise directory/src/main/scala. The exercise unit tests can be found within the exercise directory/src/test/scala.

To run the tests simply run the command sbt test in the exercise directory.

For more detailed info about the Scala track see the help page.

Submitting Incomplete Solutions

It's possible to submit an incomplete solution so you can see how others have completed the exercise.

BankAccountTest.scala

import org.scalatest.concurrent.{IntegrationPatience, Conductors}
import org.scalatest.{Matchers, FunSuite}

/** @version created manually **/
class BankAccountTest extends FunSuite with Matchers with Conductors with IntegrationPatience {
  test("open account") {
    Bank.openAccount().getBalance should be (Some(0))
  }

  test("incrementing and checking balance") {
    pending
    val acct = Bank.openAccount()
    acct.getBalance should be (Some(0))
    acct.incrementBalance(10) should be (Some(10))
    acct.getBalance should be (Some(10))
    acct.incrementBalance(10) should be (Some(20))
    acct.getBalance should be (Some(20))
  }

  test("closed account should hold no balance") {
    pending
    val acct = Bank.openAccount()
    acct.closeAccount()
    acct.incrementBalance(10)
    acct.incrementBalance(10)
    acct.getBalance should be (None)
  }

  test("incrementing balance from multiple threads") {
    pending
    val conductor = new Conductor
    import conductor._

    val acct = Bank.openAccount()

    thread("t1") {
      acct.incrementBalance(10)
      acct.getBalance should be (Some(10))
      beat should be (1)
      waitForBeat(2)
      acct.getBalance should be (Some(15))
    }

    thread("t2") {
      waitForBeat(1)
      acct.getBalance should be (Some(10))
      acct.incrementBalance(5)
      acct.getBalance should be (Some(15))
      beat should be (2)
    }
  }

  test("incrementing balance from multiple threads - concurrent updates") {
    pending
    val conductor = new Conductor
    import conductor._

    val acct = Bank.openAccount()

    thread("t1") {
      for (a <- 1 to 10)
        acct.incrementBalance(10)
    }

    thread("t2") {
      for (a <- 1 to 10)
        acct.incrementBalance(5)
    }

    whenFinished {
      acct.getBalance should be (Some(150))
    }
  }
}
trait BankAccount {

  def closeAccount(): Unit

  def getBalance: Option[Int]

  def incrementBalance(increment: Int): Option[Int]
}

object Bank {
  def openAccount(): BankAccount = new BankAccountImpl()
}

case class Account(balance : Int, opened : Boolean)

class BankAccountImpl() extends BankAccount{

  private var state = Account(0,true);

  def closeAccount(): Unit = this.synchronized({
    state = state.copy(opened = false)
  })

  def getBalance: Option[Int] = this.synchronized({
    if (state.opened) Some(state.balance) else None
  })

  def incrementBalance(increment: Int): Option[Int] = this.synchronized({
    if (state.opened) {
      state = state.copy(balance = state.balance + increment)
      getBalance
    } else None
  })
}

Community comments

Find this solution interesting? Ask the author a question to learn more.

What can you learn from this solution?

A huge amount can be learned from reading other people’s code. This is why we wanted to give exercism users the option of making their solutions public.

Here are some questions to help you reflect on this solution and learn the most from it.

  • What compromises have been made?
  • Are there new concepts here that you could read more about to improve your understanding?