GenStatem untuk Pengelolaan Status

Welcome to GenStatem! It's an OTP behavior in Erlang used to build Finite State Machines (FSMs). If your system component needs to behave differently based on its current state, GenStatem is your friend.

Think of it as a specialized tool for managing complex state logic, offering more explicit control over state transitions than a regular GenServer.

A Finite State Machine (FSM) is a mathematical model of computation that describes the behavior of a system. It can only be in one state at any given time.

• States: Distinct conditions a system can be in (e.g., "on", "off", "idle", "active").
• Events: Inputs or occurrences that trigger a change in state (e.g., "button_press", "timeout").
• Transitions: Rules that define how an event in a particular state causes a shift to a new state.

Like other OTP behaviors, GenStatem requires a callback module. This module implements specific functions that define the FSM's behavior.

The most basic function is init/1, which sets up the initial state and data for your FSM. It returns {:ok, InitialState, InitialStateData}.

In GenStatem, a state is typically an atom (e.g., :on, :off). StateData is any Erlang term that holds the internal information associated with the current state, similar to a GenServer's state.

When you transition, you specify both the new state atom and the new state data. This allows you to carry context and information across different states of your FSM.

GenStatem uses callback functions to react to events. For asynchronous events (like gen_statem:cast/2), the handle_event/4 callback is used.

The function signature is State(EventType, EventContent, StateData), where State is the current state atom and EventType indicates the type of message (e.g., :cast, :info).

The return value of your event-handling functions dictates the FSM's next action. To change state, you return a tuple: {:next_state, NewState, NewStateData}.

• NewState: The atom representing the next state.
• NewStateData: The updated state data to be carried into the new state.

If you want to stay in the current state, you can return {:keep_state, NewStateData} or {:keep_state_and_data} if data doesn't change.

GenStatem handles different types of events:

• handle_call/4: For synchronous calls (gen_statem:call/3). The caller waits for a reply.
• handle_event/4: For asynchronous casts (gen_statem:cast/2) and internal messages (gen_statem:info/2, or process messages). The caller does not wait.
• handle_info/4: A specialized version of handle_event for process messages not originating from gen_statem:cast or gen_statem:call. Often less used with state_functions mode.

We'll focus on handle_call and handle_event in our example.

Let's build a classic FSM: a light switch! It will have two states: off and on.

We'll send a toggle event to change its state. We'll also add a way to check its current status.

Here's the full Erlang module for our light switch. Run it and try interacting with it!

Consider a GenStatem module representing a door with states :closed and :open. It receives :open_door and :close_door events.

If the door is :closed and receives :open_door, it transitions to :open. If it's :open and receives :close_door, it transitions to :closed.

What is the correct return value from the closed/4 state function when it receives an :open_door event via gen_statem:cast/2?

Great job mastering GenStatem!

You've learned that GenStatem is ideal for implementing Finite State Machines, allowing you to manage complex state-dependent logic. Key takeaways:

• FSMs have states, events, and transitions.
• GenStatem uses callback modules and state functions (e.g., off/4, on/4).
• You transition between states using {:next_state, NewState, NewStateData}.
• Events can be asynchronous (cast, handled by handle_event/4) or synchronous (call, handled by handle_call/4).

This powerful behavior is a cornerstone for building robust, predictable systems in Erlang.