自定义 OTP 行为
了解 OTP 行为的结构，以及如何创建自定义通用行为来封装常见模式。
自定义 OTP 行为 是 CoddyKit 上的免费 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课时。 这是第 3 节课，共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 学习路径的一部分，你的进度在网页和 CoddyKit 应用中同步。 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程共包含 4 节课。
本课时的部分内容尚未翻译，以英文显示。
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.
常见问题解答
「自定义 OTP 行为」课时是免费的吗？
是的 — 「自定义 OTP 行为」的完整文本可在网页上免费阅读。要进行交互式练习（内置代码编辑器和全天候 AI 导师）并解锁 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程的其余内容，请升级到 CoddyKit PRO。 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程共包含 4 节课。
「自定义 OTP 行为」这节课中我会学到什么？
了解 OTP 行为的结构，以及如何创建自定义通用行为来封装常见模式。 你通过在浏览器中直接运行的动手代码来练习 Erlang OTP: Distributed & Fault-Tolerant Systems Programming，全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 需要有经验吗？
无需任何先前经验。CoddyKit 上的 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课程适合初学者到高级学习者，你可以从这里开始或从头开始，按照自己的节奏学习。 这是第 3 节课，共 4 节。
「自定义 OTP 行为」课时需要多长时间？
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动，所以你能稳步进步，并在网页和应用中从离开的地方继续。
我能在这节 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课中编写并运行代码吗？
能。每节 Erlang OTP: Distributed & Fault-Tolerant Systems Programming 课都包含内置代码编辑器，你可以在浏览器中直接编写并运行真实代码，并获得即时 AI 反馈 — 无需本地设置。