8  Many Forms, One Action: The Magic of Polymorphism

In the last chapter, we created logical “families” of classes using traits. We built a Document family with different members like PdfDocument and WordDocument. But what is the real payoff for this organization? How does it help us write better, more flexible code?

The answer lies in one of the most elegant and powerful ideas in all of programming: Polymorphism.

The word itself comes from Greek, meaning “many forms.” In programming, polymorphism is the ability for a single piece of code (a variable, a function parameter, a list) to interact with objects of many different underlying forms, all through a single, common interface.

8.1 Deepening the Analogy: Beyond the Remote

Let’s revisit our analogies and make them richer to truly grasp the concept.

  • Analogy 1: The Universal Remote Think of the “Play” button on a universal remote. The remote’s code is simple: “When the user presses the ‘Play’ button, send the ‘play’ signal to whatever device is currently selected.” The remote itself is ignorant; it doesn’t know or care if it’s talking to a Sony TV, a Samsung Blu-ray player, or a Bose sound system. It only knows that it can talk to anything that “understands” the Playable contract. The TV, the Blu-ray player, and the sound system each have their own internal way of handling the ‘play’ signal, but they all expose the same, standard button to the outside world. The remote (your main code) is simple and stable, while the devices (the concrete classes) can be varied and complex.

  • Analogy 2: The Electrical Outlet This is perhaps the most powerful analogy for polymorphism. The electrical outlet on your wall is a standard interface. It promises to provide electricity at a specific voltage and with a specific plug shape.

    • You can plug in a Lamp.
    • You can plug in a LaptopCharger.
    • You can plug in a VacuumCleaner.

    Your code (you) doesn’t need to know anything about lightbulbs, battery circuits, or vacuum motors. You just perform one single, polymorphic action: plug into the wall socket. Each device (the object) takes that standard input (the electricity) and does something completely different with it. The outlet decouples you from the details of the device. Polymorphism decouples your code from the details of the objects it works with.

8.2 Hands-On: Polymorphism in Action with Documents

Let’s use the rich family of Document classes we created in the previous chapter to see this principle in action in two major contexts: in collections and in function parameters.

8.2.1 First, A Quick Reminder of Our Document Family:

// The contract/interface
trait Document {
  val filename: String
  def open(): Unit
  def save(): Unit = println(s"Saving document: $filename...")
}

// A second ability that can be mixed in
trait Printable {
  def print(): Unit = println("Sending to the default printer...")
}

// Our concrete classes
class PdfDocument(val filename: String) extends Document with Printable {
  override def open(): Unit = println(s"Opening PDF '$filename' in a PDF reader.")
}
class WordDocument(val filename: String) extends Document with Printable {
  override def open(): Unit = println(s"Opening Word doc '$filename' in Microsoft Word.")
}
class VideoFile(val filename: String) extends Document { // Note: Not Printable
  override def open(): Unit = println(s"Playing video file '$filename' in a media player.")
}

8.2.2 Polymorphism in a Collection

This is the most common use case. We want to perform an operation on a group of related, but different, things.

// Create instances of our different document types
val resume = new PdfDocument("resume_final.pdf")
val report = new WordDocument("q3_report.docx")
val marketingVideo = new VideoFile("launch_ad.mp4")

// Create a List where every item is simply a 'Document'.
// This is possible because PdfDocument, WordDocument, and VideoFile all fulfill the Document contract.
val documents: List[Document] = List(resume, report, marketingVideo)

println("--- Opening all documents ---")
// Now for the magic. We loop through the list and perform the SAME action on each one.
for (doc <- documents) {
  // We don't need to know or care if 'doc' is a PDF, Word, or Video.
  // We just know that it IS A Document, so it MUST have an .open() method.
  doc.open()
}

Expected Output:

--- Opening all documents ---
Opening PDF 'resume_final.pdf' in a PDF reader.
Opening Word doc 'q3_report.docx' in Microsoft Word.
Playing video file 'launch_ad.mp4' in a media player.

This is the “Aha!” moment. We wrote one piece of code in our for loop (doc.open()), and it automatically did the “right thing” for each object by calling its specific, overridden version of the open method.

8.2.3 Polymorphism in a Function’s Parameters

This is an even more powerful way to write flexible and reusable code. We can write functions that operate on an entire family of objects.

  • Analogy: The Car Mechanic A good mechanic doesn’t have a separate garage for every car brand. Their sign says, “We Service All Vehicles.” They have one set of tools and processes that works on any object that fulfills the Vehicle contract.

Let’s create a “mechanic” function for our documents.

// This function accepts ANY object, as long as it IS A Document.
def processDocument(doc: Document): Unit = {
  println(s"\n--- Processing ${doc.filename} ---")
  doc.open()
  doc.save()
}

// Now we can call this SINGLE function with DIFFERENT types of objects.
processDocument(resume)
processDocument(marketingVideo)

Expected Output:

--- Processing resume_final.pdf ---
Opening PDF 'resume_final.pdf' in a PDF reader.
Saving document: resume_final.pdf...

--- Processing launch_ad.mp4 ---
Playing video file 'launch_ad.mp4' in a media player.
Saving document: launch_ad.mp4...

The processDocument function is now incredibly reusable and “future-proof.” If, next year, we invent a new MarkdownDocument class that extends Document, our existing processDocument function will work with it instantly, without requiring a single change.

8.3 Why This Changes Everything: The Strategic Value of Polymorphism

Polymorphism is not just a clever programming trick; it’s a fundamental strategy for building robust, maintainable, and flexible software.

  • Benefit 1: Decoupling (Reducing Dependencies) Our processDocument function depends only on the abstract Document trait. It is completely “decoupled” from the specific details of PdfDocument or WordDocument. This means the team working on the PDF logic can change it radically, and as long as it still fulfills the Document contract, our processDocument function doesn’t break. This is like how your computer’s USB port doesn’t care if you plug in a Logitech mouse or a SanDisk drive; it only cares about the standard USB interface.

  • Benefit 2: Extensibility (The Open/Closed Principle) This is one of the most famous principles in software design: your code should be open for extension, but closed for modification.

    • Closed for Modification: Our for loop and our processDocument function are finished. We should never have to open them up and change their code.
    • Open for Extension: Our system is wide open for new functionality. Anyone can add a new AudioDocument or ImageDocument class at any time. As long as it extends Document, all our existing processing logic will accept it seamlessly.

  • Tip: How to Spot Opportunities for Polymorphism Be on the lookout for code that manually checks the type of an object. This is a major “code smell” that often indicates a missed opportunity for polymorphism.

    Smelly Code (Before Polymorphism) 🤢: scala def openAnyFile(file: Any): Unit = { if (file.isInstanceOf[PdfDocument]) { val pdf = file.asInstanceOf[PdfDocument] pdf.open() } else if (file.isInstanceOf[WordDocument]) { val word = file.asInstanceOf[WordDocument] word.open() } } If you ever find yourself writing code like this, stop! It’s a sign that the “decision” should not be made by the caller. The decision should be embedded in the objects themselves, and you should just call a single, polymorphic method like doc.open().

8.4 Summary: Programming to a Contract

Polymorphism is the payoff for organizing our code into families with traits. It allows us to write general, simple, and stable code that interacts with a “contract” (the trait) rather than with a specific, concrete implementation (the class). This makes our systems dramatically easier to extend, maintain, and understand.

We’ve now mastered the core principles of organizing our code. We are ready to take these powerful, clean-code ideas and apply them to the world of massive-scale data in our next unit on Apache Spark.