Custom OTP Behaviors
Understand the structure of OTP behaviors and how to create your own custom generic behaviors to encapsulate common patterns.
Custom OTP Behaviors is a free Erlang OTP: Distributed & Fault-Tolerant Systems Programming lesson on CoddyKit — lesson 3 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Erlang OTP: Distributed & Fault-Tolerant Systems Programming learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Intro: What are OTP Behaviors?
You've learned about OTP behaviors like GenServer and GenStatem. They provide a standard way to build robust, fault-tolerant components.
But what if you have a recurring pattern that isn't perfectly covered by existing behaviors? This is where custom OTP behaviors come in handy!
They let you define your own generic component structure.
Why Custom Behaviors?
Creating custom behaviors offers several key advantages:
- Code Reuse: Encapsulate common logic once and reuse it across many modules.
- Consistency: Ensure all components following your behavior adhere to a specific interface and structure.
- Abstraction: Hide complex internal details, exposing a simpler API to users.
- Maintainability: Changes to the core logic only need to happen in one place.
Anatomy of a Behavior
An OTP behavior typically consists of two main parts:
- The Behavior Module: This module defines the public interface (functions users call) and often provides helper functions for the callback module. It uses the
-behaviour(gen_server)or similar attribute to link to a generic server. - The Callback Module: This is where the actual logic lives. It implements the callback functions (like
init/1,handle_call/3) required by the behavior module.
Think of it as a contract between the two.
Behavior Module: Interface
The "behavior module" is what other modules -behaviour(...) against. For custom behaviors, you'll often define a module that wraps an existing generic behavior (like gen_server) but adds your specific API.
It acts as the client-side interface for users of your custom behavior.
Key aspects:
- Defines the public functions (e.g.,
start_link/0,my_action/1). - These functions typically call
gen_server:start_link/3orgen_server:call/2internally. - It specifies the callback module using the
-callbackattribute.
Callback Module: Logic
The "callback module" is where the core functionality of your custom behavior resides. It's the module that actually implements the required functions defined by the underlying generic behavior (like gen_server or gen_statem).
- It must implement functions like
init/1,handle_call/3,handle_cast/2, etc. - These functions manage the state and respond to messages.
- This module is what the behavior module (e.g.,
gen_server) calls directly.
Counter Behavior: Start
Let's create a simple custom counter behavior. We'll wrap a gen_server to manage an integer count.
First, define the behavior module, which acts as the client API and starts the underlying gen_server.
-module(my_counter).
-behaviour(gen_server). % We wrap gen_server
-export([start_link/0, get_count/0, increment/0, decrement/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
terminate/2, code_change/3]).
% Public API for starting the counter
start_link() ->
gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
% --- gen_server callbacks (for *this* module acting as callback) ---
% This is where the initial state is set
init([]) ->
{ok, 0}. % Initial count is 0Counter Behavior: Functions
Now, let's add the public functions to interact with our counter (increment, decrement, get_count) and implement their corresponding handle_call logic.
These public functions will use gen_server:call/2 to send requests to the actual counter process.
-module(my_counter).
-behaviour(gen_server).
-export([start_link/0, get_count/0, increment/0, decrement/0]).
-export([init/1, handle_call/3, handle_cast/2, handle_info/2,
terminate/2, code_change/3]).
start_link() ->
gen_server:start_link({local, ?MODULE}, ?MODULE, [], []).
% Public API for interacting with the counter
get_count() ->
gen_server:call(?MODULE, get_count).
increment() ->
gen_server:call(?MODULE, increment).
drcrement() ->
gen_server:call(?MODULE, decrement).
% --- gen_server callbacks ---
init([]) ->
{ok, 0}.
handle_call(get_count, _From, State) ->
{reply, State, State};
handle_call(increment, _From, State) ->
NewState = State + 1,
{reply, NewState, NewState};
handle_call(decrement, _From, State) ->
NewState = State - 1,
{reply, NewState, NewState};
handle_call(_Request, _From, State) ->
{reply, {error, unknown_request}, State}.
handle_cast(_Msg, State) ->
{noreply, State}.
handle_info(_Info, State) ->
{noreply, State}.
terminate(_Reason, _State) ->
ok.
code_change(_OldVsn, State, _Extra) ->
{ok, State}.Using the Custom Counter
With our my_counter behavior defined, we can now easily use it from an Erlang shell or another module. Notice how simple the client-side code is!
You don't need to know the gen_server details; you just use the custom behavior's API.
-module(counter_app).
-export([run/0]).
run() ->
% Start our custom counter behavior
io:format("Starting counter...~n"),
my_counter:start_link(),
io:format("Current count: ~p~n", [my_counter:get_count()]),
io:format("Incrementing...~n"),
my_counter:increment(),
io:format("Current count: ~p~n", [my_counter:get_count()]),
io:format("Decrementing...~n"),
my_counter:decrement(),
io:format("Current count: ~p~n", [my_counter:get_count()]),
% Stop the counter (optional, usually supervisors handle this)
gen_server:stop(my_counter),
io:format("Counter stopped.~n").When to Use Custom Behaviors
Custom OTP behaviors are powerful, but not every component needs one. Consider creating a custom behavior when:
- You find yourself writing similar
gen_serverorgen_statemboilerplate repeatedly. - You want to enforce a specific pattern or interface across multiple components.
- You need to provide a simpler, higher-level API for a complex underlying process.
- You are building a reusable library or framework component.
Quick Check
You've learned about custom OTP behaviors. Let's test your understanding.
Recap & Next Steps
You've explored the world of custom OTP behaviors!
- We saw that custom behaviors allow you to encapsulate common patterns.
- They typically consist of a **behavior module** (public API) and a **callback module** (logic).
- By wrapping existing behaviors like
gen_server, you can create powerful, reusable components.
Mastering custom behaviors empowers you to build highly modular and consistent Erlang applications.
Frequently asked questions
Is the “Custom OTP Behaviors” lesson free?
Yes — the full text of “Custom OTP Behaviors” is free to read here on the web, and the Erlang OTP: Distributed & Fault-Tolerant Systems Programming course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Erlang OTP: Distributed & Fault-Tolerant Systems Programming course, upgrade to CoddyKit PRO.
What will I learn in “Custom OTP Behaviors”?
Understand the structure of OTP behaviors and how to create your own custom generic behaviors to encapsulate common patterns. You practise Erlang OTP: Distributed & Fault-Tolerant Systems Programming with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Erlang OTP: Distributed & Fault-Tolerant Systems Programming?
No prior experience is required. Erlang OTP: Distributed & Fault-Tolerant Systems Programming on CoddyKit is structured for beginners through advanced learners; this is — lesson 3 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Custom OTP Behaviors” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Erlang OTP: Distributed & Fault-Tolerant Systems Programming lesson?
Yes. Every Erlang OTP: Distributed & Fault-Tolerant Systems Programming lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.