Tagless Final

"If you've been working with Scala, especially in the pure functional programming world, you've probably heard of the tagless final pattern. The tagless final pattern solves the difficulty of extending a data type with both new data variants and new operations on those data types without modifying existing code, while maintaining static type safety which is something called the Expression Problem."

"sealed trait Operationcase class CreditCardCharge(amount: Double, cardNumber: String) extends Operationcase class WalletTransfer(amount: Double, walletId: String) extends Operationcase class BankTransfer(amount: Double, accountNumber: String) extends Operationdef processOperation(op: Operation): String = op match { case CreditCardCharge(amount, cardNumber) => s"Charged $amount to credit card ending in ${cardNumber.takeRight(4)}" case WalletTransfer(amount, walletId) => s"Transferred $amount from wallet $walletId" case BankTransfer(amount, accountNumber) => s"Transferred $amount from bank account $accountNumber"}"

"When reality hits This is when things get interesting, your Product Manager walks in while you're sipping your coffee and goes "The fraud team wants risk scores as numbers and we need to audit transactions with timestamps" Now our previous solution needs to return differ"

Scala’s tagless final pattern provides a way to extend data types with new variants and new operations without modifying existing code while preserving static type safety. A simple payment example defines a sealed Operation trait with case classes for CreditCardCharge, WalletTransfer, and BankTransfer, and a processOperation function that pattern-matches to produce string results. Real requirements can diverge: risk scores as numeric values and audited timestamps require different result shapes. The mismatch between evolving outputs and a fixed algebraic data type motivates alternative designs such as the tagless final approach to achieve extensibility and type safety.

Read at Medium