erlang的gen_fsm

       erlang的gen_fsm俗称为有限状态机，拿一个游戏的怪物来做例子，怪物站在地图里的状态是游荡状态，这个时候，一个人物出现在他的实现范围内，那么他的状态就会变成追击状态，当人物打死怪物就会变成死亡，或者人物跑入了安全区，那么怪物又变成游荡状态了，那么这类有限的状态，因为触发事件而导致的状态转换就是我所理解的有限状态机。

       我在这里确确实实有很多疑问，不过这些以后再说！以下是gsm的模板块和回调函数

 

-module(whatever).
 
-behaviour(gen_fsm).

-export([start_link/0]).


-export([init/1, handle_event/3, handle_sync_event/4, handle_info/3, terminate/3, code_change/4]).
 

start_link() ->
    %%启动一个sup的子进程这个进程，这个方法要直接或者间接的被super调用，%%很生涩，其实不难理解
    gen_fsm:start_link({local, ?MODULE}, ?MODULE, [], []).
 
%%start_link以后调用init初始化状态和state一些参数State
init([]) ->
　　 {ok, state, State}.

%%同步调用
handle_event(_Event, StateName, State) ->
    {next_state, StateName, State}.

%%异步调用
handle_sync_event(_Event, _From, StateName, State) ->
    Reply = ok,
    {reply, Reply, StateName, State}.
 
%%消息调用
handle_info(_Info, StateName, State) ->
    {next_state, StateName, State}.
 
%%技术进程
terminate(_Reason, _StateName, _State) ->
    ok.
 
code_change(_OldVsn, StateName, State, _Extra) ->
    {ok, StateName, State}.

%%建议把帮助文档里关于gserver和gfsm的内容看一遍，很便于理解这些框架的工作机制，以后工作中也
%%方便我们去查找

        这只是基础的回调函数模块知道了，很多人不知道改什么时候用哪个模块，其实这是个很大的问题，这是自己在给自己找麻烦，曾经我也是这样，帮助文档和基本模块都给了我，我却不知道该怎么写一个功能，现在想来那时候有点蠢，就像fsm，一个事件发生了，如果你是需要得等待一个回调结果，那就使用同步调用，如果不需要那就直接用异步调用就可以了，而我们在开始的时候调用init，就在init里面写一个你自己需想要处理的状态就可以，这里要写的是什么呢，一般情况下都是写一个ets进去，如果写的程序大一些，需要进程间共享内存，那么你就需要ets！（如果启动的进程的callback函数出现异常会按照super的规则来处理，说白了就是被终止或者被重启）

        我一直有一个疑问，gen_server和gen_fsm之间的关系，我来打个比方，gen_server可不可以完成一个有限自动机的需求，答案是无疑的，可以!  那么我们为什么还要使用gen_fsm呢！如果硬要我说的话，我觉着这是一个对不同情况的处理思想问题，例如gserver 他的主要目的就是作为一个小型server框架，完成的就是客户端和服务器的逻辑，更多时候我们只依靠他来完成两端的一些连接交互等等功能！而gfsm呢就是一个有限状态机的框架，帮助我们完成一个对象的有限状态转换的框架，我们的确可以用自己的方式或者是使用gserver来完成gfsm的逻辑，但是这样做其实很麻烦，而gfsm给我们提供了一套的现行高效的代码，这可能就是erlang编程的一个规范而已！（gen_event则是实现一个事件处理器，专门负责处理一个事件发生后对对象产生的影响）