Recently, Professor Zhou Ligong has released his long-awaited book titled "Programming and Data Structure," which has been in development for several years. The electronic version of the book is now available for free download among electronic engineers and college students. With Professor Zhou's permission, the content of this book is being serialized here.
> > > 1.1.1 Action Class
The previous section explained the derivation process of the State pattern and provided a detailed implementation, using simple print statements as examples of four different actions. However, in real-world applications, actions often change dynamically as they are executed directly within event handling functions. For instance, the card event handler for the LOCKED state is defined as follows:
```c
void locked_card(turnstile_t *p_turnstile)
{
turnstile_state_set(p_turnstile, &unlocked_state);
printf("unclock"); // Execute the unlock action
}
```
As you can see, any change in the action requires modifying the corresponding event handler. To address this, it's better to encapsulate the gate actions into a dedicated action class. This approach is illustrated in Figure 4.12.
In Listings 4.23 and 4.24, we show the declaration and implementation of an action class. You might wonder why such a simple action would require a full class declaration and implementation. The reason is that by separating actions into their own class, we can manage changes more effectively, making the software more scalable and maintainable.
**Listing 4.23: Action Function Declarations (turnstile_action.h file contents)**
```c
#pragma once
void turnstile_action_lock(void);
void turnstile_action_unlock(void);
void turnstile_action_alarm(void);
void turnstile_action_thankyou(void);
```
**Listing 4.24: Action Function Implementation (turnstile_action.c file contents)**
```c
void turnstile_action_lock(void)
{
printf("clock");
}
void turnstile_action_unlock(void)
{
printf("unclock");
}
void turnstile_action_alarm(void)
{
printf("alarm");
}
void turnstile_action_thankyou(void)
{
printf("thank you");
}
```
Each of these functions corresponds to an action—lock, unlock, alarm, and thankyou. By separating the actual action logic from the state machine, the system becomes more modular. For example, the `locked_card` function, which handles the card event in the LOCKED state, now looks like this:
```c
void locked_card(turnstile_t *p_turnstile)
{
turnstile_state_set(p_turnstile, &unlocked_state);
turnstile_action_unlock(); // Perform the unlock action
}
```
This design is clean and efficient because it decouples the state transition logic from the actions themselves. As a result, even if another FSM with entirely different behavior is introduced, these action interfaces can still be used without any issues.
Since no data is required during the execution of these actions, the action class only contains methods and no attributes. Therefore, there's no need to define a specific structure type. However, in more complex scenarios, the action class may include some data, as shown below:
```c
typedef struct _turnstile_action {
// some data
} turnstile_action_t;
```
When the actions change, only the relevant method in the action class needs to be updated, while the state machine’s event handlers remain unaffected. This separation ensures flexibility and maintainability in the overall system design.
huasheng speaker,huasheng speaker Used in telephone,huasheng speaker used in car
Gaoyou Huasheng Electronics Co., Ltd. , https://www.yzelechs.com