Building Polymorphic Systems

Welcome back. In earlier lessons, you learned how protocols enable polymorphism by dispatching on data types, and you also defined behaviours to enforce module contracts. In this lesson, you will put the protocol side of that knowledge into action to build a small, extensible validation system. We will create a protocol, implement it for multiple structs, and run a unified workflow that works across different data types without conditionals.

defprotocol Validator do
  def valid?(data)
end

defmodule Email do
  defstruct address: ""
end

defmodule PhoneNumber do
  defstruct number: ""
end

defimpl Validator, for: Email do
  def valid?(%Email{address: address}) do
    String.contains?(address, "@") and String.length(address) > 5
  end
end

defimpl Validator, for: PhoneNumber do
  def valid?(%PhoneNumber{number: number}) do
    String.length(number) == 10 and String.match?(number, ~r/^\d+$/)
  end
end

Explanation:

• defprotocol Validator defines a single function, valid?/1. Each data type can supply its own implementation.
• Email and PhoneNumber are simple structs. Protocol dispatch will use the struct type at runtime.
• The Email implementation checks for an “@” and a minimum length.
• The PhoneNumber implementation enforces 10 digits using a regex.
• Pattern matching in the function heads pulls the needed fields cleanly.

Note: Protocol dispatch is resolved efficiently after compilation (protocol consolidation). You get dynamic behavior with compile-time optimization.

defmodule ContactValidator do
  def validate_contacts(contacts) do
    Enum.map(contacts, fn contact ->
      {contact, Validator.valid?(contact)}
    end)
  end
end

Explanation:

• validate_contacts/1 iterates over mixed data, calls Validator.valid?/1, and pairs each item with its validation result.
• The function does not need to know the concrete type. That is the core benefit of polymorphism.

defmodule Solution do
  def main do
    contacts = [
      %Email{address: "alice@example.com"},
      %Email{address: "invalid"},
      %PhoneNumber{number: "1234567890"},
      %PhoneNumber{number: "123"}
    ]

    results = ContactValidator.validate_contacts(contacts)
    Enum.each(results, fn {contact, valid} ->
      IO.puts "#{inspect(contact)} - Valid: #{valid}"
    end)
  end
end

Solution.main()

Explanation:

• You build a mixed list of Email and PhoneNumber structs.
• ContactValidator.validate_contacts/1 triggers protocol dispatch for each item.
• The output shows each contact with a true/false result, proving that one call site can handle multiple types without case statements.

Note: This design follows the open/closed principle. To support a new contact type (e.g., Address), define a struct and a defimpl Validator, for: Address, then everything else “just works.”

You created a protocol, implemented it for two structs, and wired a small workflow that validates mixed data without branching. This is a practical pattern for building flexible systems: keep call sites simple, push type-specific logic into protocol implementations, and add new types by extension, not modification.