Scala
Completed
-
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
65: Ordering and Ordered Traits
How do I make my custom classes work with comparison operators like < and >?
If you've ever tried to sort a list of custom case classes, you've probably hit a wall where Scala tells you it doesn't know how to compare them. To fix this, you mix in the Ordered[T] trait. When you do this, you're essentially telling Scala: "This class knows how to compare itself to another instance of the same type."
The only thing you have to do is implement the compare method. It returns an integer: negative if this object is "less than" the other, zero if they're equal, and positive if it's "greater than".
case class Book(title: String, pages: Int) extends Ordered[Book] {
def compare(that: Book): Int = this.pages - that.pages
}
val book1 = Book("Scala Guide", 300)
val book2 = Book("Quick Start", 100)
println(book1 > book2) // true
println(book2 < book1) // true
By implementing Ordered, you get <, >, <=, and >= for free. It's a huge quality-of-life improvement for your code.
Wait, is Ordered the same thing as Ordering?
This is where most people get tripped up. They look similar, but they serve different purposes. Think of Ordered as "internal" and Ordering as "external."
Ordered is a trait you mix into your class. It defines the natural ordering of that object. But what happens if you don't own the class? You can't just go into the Scala standard library and add extends Ordered to the String or Int classes. That's where Ordering[T] comes in.
Ordering is a separate object that knows how to compare two other objects. It's a "type class" pattern. If you look at the signature of List.sorted, it doesn't actually require the elements to be Ordered; it asks for an implicit Ordering to be available in the scope.
What if I need to sort the same data in different ways?
The problem with Ordered is that you can only have one natural ordering. If you've defined Book to be ordered by page count, you're stuck with that. But in a real app, you'll probably want to sort books by title, then by author, then by date published.
This is where I always reach for Ordering. You can define multiple Ordering objects for the same type and just pass the one you need to the sorting method.
case class Book(title: String, pages: Int)
object BookOrderings {
implicit val byPages: Ordering[Book] = Ordering.by(_.pages)
implicit val byTitle: Ordering[Book] = Ordering.by(_.title)
}
import BookOrderings._
val library = List(Book("Zebra", 10), Book("Apple", 500), Book("Mantis", 100))
// Use byPages (because it's the first implicit found or explicitly passed)
println(library.sorted(byPages))
// Use byTitle
println(library.sorted(byTitle))
I personally prefer Ordering.by because it's concise. You don't have to write the manual subtraction or comparison logic; you just tell Scala which field to look at.
📋 Practical Task
Implement a Multi-Criteria Product Sorter
You are building a small inventory system for an electronics store. You have a Product case class with name: String, price: Double, and rating: Double.
Your task is to implement the following:
- Make
ProductextendOrdered[Product]so that the "natural order" is based on price (cheapest first). - Create a separate
Ordering[Product](perhaps inside a companion object) that sorts products by rating in descending order (highest rating first). - In your main method, create a list of 3-4 products and demonstrate both sorting methods: one using the natural
.sortedcall and one using your custom rating-basedOrdering.
There are no comments for now.