Home
Elixir
Elixir structs

Master Remote Control Car in Elixir: Complete Learning Path

Master Remote Control Car in Elixir: Complete Learning Path

This comprehensive guide explores how to model a remote control car using Elixir's powerful features. You will learn to manage state, define behaviors with modules, and structure data with structs—core concepts for building robust, functional applications. This module is your first step towards mastering immutable state transformations in Elixir.

You remember the thrill of a new remote control car. The simple joy of pressing a button and seeing it whiz across the floor. But have you ever stopped to think about the logic behind it? How does it know its battery level, how far it's gone, or what to do when you press "drive"? Translating that simple real-world object into code can be surprisingly challenging, especially in a functional programming language like Elixir where data is immutable.

You might be struggling with how to represent something that inherently *changes*—like a car's position or battery—in a language that forbids changing data. This is a common hurdle for developers transitioning to a functional mindset. This guide is here to turn that confusion into clarity. We will walk you through the elegant Elixir way of modeling state and behavior, using the fun and familiar concept of a remote control car. By the end, you won't just have a virtual car; you'll have a deep understanding of structs, modules, and the art of state transformation, a cornerstone of professional Elixir development.

What is the Remote Control Car Module?

The Remote Control Car module, a foundational part of the kodikra.com Elixir curriculum, is designed to teach the fundamental principles of data structuring and state management in a functional paradigm. It's not just about a toy car; it's a practical exercise in modeling real-world objects and their interactions within an immutable environment.

At its core, this module challenges you to represent two key components:

  • The Car's State: This includes its properties at any given moment, such as battery percentage and distance driven. In Elixir, we use structs to define this structured, named data.
  • The Car's Behavior: These are the actions the car can perform, like driving forward or displaying its current status. We contain these actions within a module, which acts as the "remote control" or API for our car's state.

The central lesson is learning to manage changes to the car's state. Since Elixir data is immutable, you cannot simply change the car's battery level. Instead, every action, like driving, must produce a brand new car struct with the updated state. This concept of state transformation is crucial for writing predictable, concurrent, and bug-resistant Elixir code.

Why is Mastering This Concept Crucial in Elixir?

Understanding how to model state with structs and modules is not just an academic exercise; it is the bedrock of building almost any non-trivial Elixir application. Elixir's design choices, particularly immutability and the Actor Model (via OTP), are built upon this foundation of explicit state transformations.

Here’s why this module is so important:

  • Embracing Immutability: The biggest mental shift for many developers is immutability. This module forces you to confront it head-on. By learning that drive(car) returns a new_car, you internalize the core functional pattern, which eliminates a whole class of bugs related to shared mutable state found in object-oriented languages.
  • Foundation for OTP: Elixir's superpower is the Open Telecom Platform (OTP), which provides battle-tested abstractions for concurrency and fault tolerance like GenServer. A GenServer is essentially a process that manages state. The logic inside a GenServer is precisely what you learn here: receiving a message (an action) and transforming its current state into a new state.
  • Clear Separation of Data and Logic: This pattern promotes clean architecture. The struct is pure data—it has no methods attached. The module is pure behavior—it contains the functions that operate on that data. This separation makes code easier to reason about, test, and maintain.
  • Enhanced Testability: Pure functions that take data and return new data are incredibly easy to test. You don't need to mock complex objects or worry about hidden side effects. You simply provide an input car struct and assert that the output car struct has the expected values.

Mastering this simple car model gives you the mental framework to build complex systems, from web request handlers that transform a connection struct (like in Phoenix) to state machines that manage IoT devices.

How to Implement the Remote Control Car in Elixir

Let's break down the implementation step-by-step. We will define the car's data structure, create the module for its behaviors, and write the functions to control it. This entire process can be explored interactively using Elixir's `iex` (Interactive Elixir) shell.

What: Defining the Car's State with Structs

First, we need to define the "shape" of our car's data. A struct is perfect for this. It's a tagged map that provides compile-time checks and default values, making our data more robust than a plain map.

We'll create a module named RemoteControlCar and use the defstruct macro inside it to define our car's attributes. For this basic model, we need to track the battery percentage and the distance driven.


# lib/remote_control_car.ex
defmodule RemoteControlCar do
  @moduledoc """
  This module defines the state and behavior of a remote control car.
  """

  @enforce_keys [:battery_percentage, :distance_driven]
  defstruct [:battery_percentage, :distance_driven]

  # ... functions will go here ...
end

Here, defstruct creates a struct named %RemoteControlCar{} with two fields: :battery_percentage and :distance_driven. The @enforce_keys attribute is a best practice that ensures we can't create a struct without specifying these essential values, preventing runtime errors.

How: Creating Behavior with Modules and Functions

Now that we have our data structure, let's add the functions (the behavior) to the RemoteControlCar module. These functions will be our "API" for interacting with the car.

1. Creating a New Car

We need a "constructor" function to create a new car with default starting values: 100% battery and 0 distance driven.


defmodule RemoteControlCar do
  # ... struct definition ...

  @doc """
  Creates a new car with a full battery and zero distance driven.
  """
  def new() do
    %RemoteControlCar{
      battery_percentage: 100,
      distance_driven: 0
    }
  end
end

You can test this in iex:


$ iex -S mix
iex> car = RemoteControlCar.new()
%RemoteControlCar{battery_percentage: 100, distance_driven: 0}

2. Displaying Information

Let's create functions to "read" the car's state and display it in a user-friendly format. These are simple accessor functions that use pattern matching in the function head to extract values from the struct.


defmodule RemoteControlCar do
  # ... struct and new() ...

  @doc "Returns the car's remaining battery as a string."
  def display_battery(%RemoteControlCar{battery_percentage: battery}) do
    "Battery at #{battery}%"
  end

  @doc "Returns the car's total distance driven as a string."
  def display_distance(%RemoteControlCar{distance_driven: distance}) do
    "Distance driven: #{distance} meters"
  end
end

Notice the %RemoteControlCar{...} syntax in the function argument. This is pattern matching. It ensures the function only runs if it receives a RemoteControlCar struct and conveniently binds the value of the :battery_percentage key to the battery variable.

3. The Core Logic: Driving the Car

This is where the concept of immutable transformation shines. The drive/1 function will take a car struct as input. If the battery is not dead, it will return a new car struct with an increased distance and a decreased battery. If the battery is dead, it will return the original car, unchanged.


defmodule RemoteControlCar do
  # ... other functions ...

  @doc """
  Drives the car, updating its distance and battery.
  Returns a new car struct with the updated state.
  If the battery is at 0, it returns the car unchanged.
  """
  def drive(%RemoteControlCar{battery_percentage: 0} = car) do
    # Battery is dead, return the car as is.
    car
  end

  def drive(%RemoteControlCar{battery_percentage: battery, distance_driven: distance} = car) do
    # Return a NEW struct with updated values.
    %RemoteControlCar{car | 
      battery_percentage: battery - 1,
      distance_driven: distance + 20
    }
  end
end

We use two function clauses for drive/1. Elixir tries to match them from top to bottom.

  1. The first clause uses a guard in the pattern match: battery_percentage: 0. It only matches a car with a dead battery and simply returns it.
  2. The second clause matches any other car, calculates the new state, and returns a new struct. The %{car | ...} syntax is a clean way to create a new struct based on an existing one.

This is the essence of functional state management. We never modify the original car. We always create a new one.

  ● Initial State
  │
  ▼
┌──────────────────┐
│ %Car{battery: 100, │
│      distance: 0}  │
└────────┬─────────┘
         │
         │ Passes through
         ▼
  ┌────────────────┐
  │ drive(car) fn  │
  └────────┬───────┘
           │
           │ Creates a new struct
           ▼
┌──────────────────┐
│ %Car{battery: 99,  │
│      distance: 20} │
└────────┬─────────┘
         │
         ▼
    ● New State

Where is This Pattern Used in Real-World Applications?

The "data structure + module of functions" pattern is ubiquitous in the Elixir ecosystem. What you learn with the remote control car scales directly to professional, large-scale applications.

  • Phoenix Web Development: In the Phoenix framework, the %Plug.Conn{} struct represents an entire web request. Each function (a "plug") in the request pipeline takes the conn struct as input and returns a new, transformed conn struct as output. This makes the flow of data through a web request explicit and easy to debug.
  • Ecto Schemas: When you work with databases using Ecto, your schemas are structs. When you use a changeset to validate user input, you are applying transformations that take a schema struct and data, and return a changeset struct, which may contain a valid, updated schema struct.
  • State Machines: Any system that can be modeled as a state machine (e.g., an order fulfillment process, a user authentication flow) is perfectly suited to this pattern. Each event is a function that takes the current state struct (e.g., %Order{status: :paid}) and returns a new state struct (e.g., %Order{status: :shipped}).
  • Game Development: The state of a game character (health, position, inventory) can be held in a struct. Each player action or game tick calls a function that transforms the character's current state into their next state.
  • IoT and Embedded Systems: Using Nerves, you can build Elixir applications for embedded devices. The state of a device's sensors and actuators can be managed in a struct, with functions processing incoming data and producing new state and commands.

The logic is always the same: data is data, behavior is behavior, and state changes are explicit transformations.

   ┌────────────────┐
   │ Module         │
   │ (The Behavior) │
   └───────┬────────┘
           │
           │ Defines and operates on
           ▼
┌───────────────────┐
│                   │
│  def function(struct) do  │
│    ...            │
│    new_struct     │
│  end              │
│                   │
└─────────┬─────────┘
          │
          │ Takes and returns
          ▼
   ┌────────────────┐
   │ Struct         │
   │ (The Data/State) │
   └────────────────┘

Common Pitfalls and Best Practices

As you work through this module, you might encounter some common functional programming hurdles. Being aware of them will help you write cleaner, more idiomatic Elixir code.

Best Practice / Do Pitfall / Don't
Use Pattern Matching Extensively. Use it in function heads to destructure structs and provide different function clauses for different states (like the dead battery case). Don't use `if/else` or `case` statements when pattern matching on function clauses will do. Function clauses are often more readable and declarative.
Always Return a New Struct for State Changes. This is the core of immutability. Your functions should be "pure" transformations. Don't try to find a way to modify the struct "in-place." This is not how Elixir works and will lead to confusion. The original data is never changed.
Use `@doc` and `@moduledoc` to document your code. This makes your module's API clear to others (and your future self) and allows tools to generate documentation automatically. Don't leave your public functions undocumented. It's hard for others to understand the purpose, arguments, and return value of a function without documentation.
Define a `new/0` or `new/1` function as a constructor. This provides a clear and conventional entry point for creating your struct with valid default or initial values. Don't rely on creating the struct manually everywhere in your code. A constructor function centralizes the creation logic.
Keep your data struct and core logic in the same module. For this pattern, it's idiomatic to have `defstruct` and the functions that operate on it in one place (e.g., `RemoteControlCar`). Don't split the struct definition from its primary functions into different files. This can make the relationship between the data and its behavior harder to follow.

Your Learning Path: Step-by-Step

This module in the kodikra.com curriculum is designed to be your hands-on introduction to these critical Elixir concepts. By completing the exercise, you will solidify your understanding and be prepared for more advanced topics.

Follow this progression to get the most out of the material:

  1. Start with the Core Challenge: The main exercise will guide you through building the struct and functions we've discussed.
  2. Experiment in `iex`: After implementing the solution, open an `iex` session. Create a car, drive it multiple times, and observe how the state changes with each new struct that is returned. This interactive exploration is invaluable.
  3. Refactor and Refine: Look at your solution. Could you use pattern matching more effectively? Is your documentation clear? Try to improve your initial implementation based on the best practices.

Completing this module will give you the confidence to tackle more complex state management challenges in Elixir.

Frequently Asked Questions (FAQ)

Why use a `struct` instead of a plain `map`?

While a struct is technically a map underneath, it provides two key advantages. First, it gives your data a name (e.g., `%RemoteControlCar{}`), making it clear what kind of data you're working with. Second, it provides compile-time checks; if you misspell a key when accessing or updating a struct, Elixir will raise an error, catching bugs early. A plain map would silently return `nil`.

Isn't creating a new data structure on every change inefficient?

This is a common concern, but it's not an issue in practice. Elixir's underlying BEAM virtual machine is highly optimized for this. When you create a "new" struct from an old one, it doesn't copy all the data. It performs "structural sharing," meaning the new struct points to the memory locations of any unchanged data from the old one, only allocating new memory for the fields that actually changed. This is very fast and memory-efficient.

How would I handle more complex actions, like turning the car?

You would simply add more fields to your struct (e.g., `:direction` or `:angle`) and more functions to your module (e.g., `turn_left(car)`, `turn_right(car)`). Each new function would take the car struct and return a new one with the updated direction, leaving other fields like battery and distance untouched (unless the action also affects them).

What's the difference between `@enforce_keys` and just defining keys in `defstruct`?

defstruct defines the allowed keys and their default values (which is `nil` if not specified). However, it still allows you to create a struct while omitting some keys. @enforce_keys adds a compile-time guarantee that you *must* provide a value for the specified keys when creating a new struct, which helps prevent bugs from missing data.

Can I add functions directly inside a `defstruct`?

No, this is a key difference from object-oriented programming. A struct is purely for data. The functions that operate on that data live within the surrounding module but are separate from the data definition itself. This separation of data and behavior is a core tenet of functional programming.

How do I test these functions?

You would use Elixir's built-in testing framework, ExUnit. Because these are pure functions, testing is straightforward. For example, to test the `drive` function, you would create a starting car struct, pass it to `RemoteControlCar.drive/1`, and then assert that the returned struct has the expected new values for distance and battery.

Conclusion: Your First Step to Functional Mastery

The Remote Control Car module is far more than a simple coding exercise. It is a microcosm of the entire functional programming paradigm as implemented in Elixir. By building this small system, you have practiced the fundamental skills required for large-scale, concurrent, and fault-tolerant applications: defining clear data structures, separating data from behavior, and managing state through immutable transformations.

The patterns you've learned here—using structs for state and modules for behavior—will appear again and again on your journey. As you progress to building web applications with Phoenix or concurrent systems with OTP, you will find yourself returning to this foundational understanding of how to handle data that changes over time. You now have the essential building block for thinking functionally in Elixir.

Disclaimer: All code examples and concepts are based on modern Elixir (version 1.16+). The principles discussed are fundamental and stable, but always consult the official Elixir documentation for the latest syntax and features.

Ready to continue your journey? Back to the complete Elixir Guide on kodikra.com.

Published by Kodikra — Your trusted Elixir learning resource.

Post a Comment