-
Section 1: Getting Started
-
Section 2: Core Syntax
-
Section 3: Object-Oriented Scala
-
Section 4: Functional Scala
-
Section 5: Collections in Depth
-
Section 6: Type System
-
Section 7: Concurrency and Ecosystem
-
Section 8: Practical Projects
-
Section 9: Interview Practice
-
Section 10: Data Structures and Algorithms in Scala
-
Section 11: More Practice Exercises
-
Section 12: Advanced Functional Patterns
-
Section 13: More Ecosystem
-
Section 14: Scala Collections Library Deep Dive
-
Section 15: Scala Standard Library Deep Dive
-
Section 16: Akka Ecosystem Deep Dive
-
Section 17: Cats and Cats Effect Deep Dive
-
Section 18: Play Framework Deep Dive
-
Section 19: Apache Spark with Scala Deep Dive
-
Section 20: Scala Build Tools Deep Dive
-
Section 21: Scala 3 Specific Features
-
90: Union and Intersection Types
-
Section 22: Scala Testing Deep Dive
-
Section 23: Functional Domain Modeling
-
Section 24: More Data Structures and Algorithms in Scala
-
Section 25: Scala for Data Engineering
-
Section 26: More Practical Projects
-
Section 27: More Interview and Review
-
Section 28: ZIO Ecosystem Deep Dive
-
Section 29: Scala for Machine Learning
-
Section 30: Scala Microservices Architecture
-
Section 31: Scala Type System Deep Dive
-
Section 32: More Practice and Drills
-
Section 33: Scala Performance Deep Dive
-
Section 34: Scala Ecosystem Tooling
-
Section 35: Scala for Reactive Systems
-
Section 36: More Real-World Case Studies
-
Section 37: Scala for Financial Systems
-
Section 38: Scala GraphQL and gRPC
-
Section 39: More Final Projects
-
Section 40: More Interview and Final Review
-
Section 41: Scala for Streaming Data
-
Section 42: Scala Security Practices
-
Section 43: More Language Deep Dive
-
Section 44: Scala Command-Line Tools
-
Section 45: Scala Documentation and Style
-
Section 46: Scala Dependency Management
-
Section 47: More Practical Backend Patterns
-
Section 48: Scala for Event-Driven Architecture
-
Section 49: More Practice Drills Round 2
-
Section 50: Scala Compiler Deep Dive
-
Section 51: Scala for Web Frontends
-
Section 52: More Data Engineering Practice
-
Section 53: Scala Observability
-
Section 54: More Advanced Practice Projects
-
Section 55: Scala for Legacy Java Integration
-
Section 56: More Testing Practice
-
Section 57: Final Mastery Review
-
Section 58: Scala History and Ecosystem Context
-
Section 59: More Concurrency Patterns
-
Section 60: Scala for Configuration Management
-
Section 61: More Domain Modeling Practice
250: Practice Exercise: Modeling a Multi-Currency Wallet System
I've been thinking about how we'd actually implement a multi-currency wallet. On the surface, it seems trivial—just a list of numbers, right? But as soon as you start coding it, you realize how quickly things can get messy if you don't lean into Scala's type system. Let's try to build this together, starting with the most naive approach and seeing where it breaks.
The "Quick and Dirty" Approach
My first instinct is usually just to use a Map[String, Double]. The string is the currency code (like "USD"), and the double is the amount. Let's see how that looks:
case class Wallet(balances: Map[String, Double]) {
def addFunds(currency: String, amount: Double): Wallet = {
val currentBalance = balances.getOrElse(currency, 0.0)
Wallet(balances + (currency -> (currentBalance + amount)))
}
}
I can run this, and it works. I can add "USD" or "EUR". But I already hate it. Why? Because I can pass "Potato" as a currency and the compiler won't blink. Also, using Double for money is a cardinal sin in software engineering because of floating-point precision errors. If I'm moving millions of dollars, those tiny rounding errors become very real legal problems.
Tightening the Screws with ADTs
I want the compiler to stop me from using fake currencies. I'll switch to a sealed trait. This way, I can define exactly which currencies our system supports. I'll also swap Double for BigDecimal to keep the decimals precise.
sealed trait Currency
case object USD extends Currency
case object EUR extends Currency
case object BTC extends Currency
case class Wallet(balances: Map[Currency, BigDecimal]) {
def addFunds(currency: Currency, amount: BigDecimal): Wallet = {
val currentBalance = balances.getOrElse(currency, BigDecimal(0))
Wallet(balances + (currency -> (currentBalance + amount)))
}
}
This feels much safer. If I try to pass a random string now, it's a compile-time error. Now, let's think about spending. I want to subtract an amount, but I can't let the balance go negative.
Wrestling with the Balance Map
If I just subtract the value, I might end up with -50 USD. I need a way to signal that the transaction failed. I could throw an exception, but that's lazy. Let's use Either. It's much more idiomatic in Scala to return the error as a value.
def spendFunds(currency: Currency, amount: BigDecimal): Either[String, Wallet] = {
val currentBalance = balances.getOrElse(currency, BigDecimal(0))
if (currentBalance >= amount) {
Right(Wallet(balances + (currency -> (currentBalance - amount))))
} else {
Left(s"Insufficient funds in $currency")
}
}
Wait, I just noticed something. If the balance for a currency hits exactly zero, the map still keeps that entry. It's not a huge deal, but it's cluttered. I can use filter or a conditional to remove the key if the value is zero. Actually, let's keep it simple for now and focus on the logic. The real challenge is: what if I want to see my total value in a single "base" currency?
Handling Exchange Rates
To do a total valuation, I can't just sum the map because you can't add 1 BTC to 1 USD and get 2 of "something". I need an exchange rate provider. I'll model this as a simple function that takes two currencies and returns a rate.
type ExchangeRateProvider = (Currency, Currency) => BigDecimal
def calculateTotalValue(base: Currency, rates: ExchangeRateProvider): BigDecimal = {
balances.foldLeft(BigDecimal(0)) { case (acc, (currency, amount)) =>
val rate = rates(currency, base)
acc + (amount * rate)
}
}
I just realized a potential bug here: what if the ExchangeRateProvider doesn't have a rate for a specific pair? Right now, my type signature assumes it always returns a BigDecimal. In a real system, that function should probably return an Option[BigDecimal]. If I can't find a rate, the whole valuation should probably fail. It's better to be explicitly "Unknown" than to accidentally assume a rate of 0.0 and tell a user they are broke when they actually have a lot of Bitcoin.
📋 Practical Task
Exercise: Implementing the Cross-Currency Transfer
You have the basic Wallet system. Your task is to implement a new method called transferFunds. This method should allow a user to move value from one currency to another within the same wallet, using a provided exchange rate.
Requirements:
- The method signature should be:
def transferFunds(from: Currency, to: Currency, amount: BigDecimal, rate: BigDecimal): Either[String, Wallet]. - The
amountis the amount being taken out of thefromcurrency. - The amount added to the
tocurrency should beamount * rate. - The transfer must fail (return a
Left) if the wallet has insufficient funds in thefromcurrency. - The method must return a new
Walletinstance with both balances updated if the transfer is successful.
Starter Code:
sealed trait Currency
case object USD extends Currency
case object EUR extends Currency
case object BTC extends Currency
case class Wallet(balances: Map[Currency, BigDecimal]) {
// Your transferFunds implementation goes here
}There are no comments for now.