# Why do we needs act\_as\_state\_machine?

**URL:** <https://www.ruby-forum.com/t/why-do-we-needs-act-as-state-machine/177496>\
**Category:** Rails\
**Created:** [October 19, 2009, 8:19am UTC](https://www.ruby-forum.com/t/why-do-we-needs-act-as-state-machine/177496 "2009-10-19T08:19:29Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![rubyernewbie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/9dc877/32.png) [@rubyernewbie](https://www.ruby-forum.com/u/rubyernewbie)\
**Post date:** [October 19, 2009, 8:19am UTC](https://www.ruby-forum.com/t/why-do-we-needs-act-as-state-machine/177496/1 "2009-10-19T08:19:29Z")

</div>

I kind of new at this…please correct me if I’m wrong.  
state\_machine do  
state :red  
state :green  
state :yellow

## ---------------a example--------------- event :change\_color do transitions :to =\> :red, :from =\> [:yellow], :on\_transition =\> :catch\_runners transitions :to =\> :yellow, :from =\> [:green] transitions :to =\> :green, :from =\> [:red] end end

## it turn yellow to red and trigger catch\_runners action. we can use

## if state == yellow state = red catch\_runner end

instead of it.  
so why do we needs act\_as\_state\_machine? a wrapper ? make thing simple?

---

<div class="post-metadata">

**Author:** ![rubyernewbie](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/9dc877/32.png) [@rubyernewbie](https://www.ruby-forum.com/u/rubyernewbie)\
**Post date:** [October 19, 2009, 3:32pm UTC](https://www.ruby-forum.com/t/why-do-we-needs-act-as-state-machine/177496/2 "2009-10-19T15:32:15Z")

</div>

Zhenning G. wrote:

> * * *
> 
> ## if state == yellow state = red catch\_runner end
> 
> instead of it.  
> so why do we needs act\_as\_state\_machine? a wrapper ? make thing simple?

You are actually illustrating the point to state machines. Yes, in this  
simple example you can implement them using a series of conditionals,  
but not every state machine is this simple. You could end up with a lot  
of conditionals and the code could end up being difficult to follow.

Good design is not always about producing the fewest number of lines.  
Sometimes a more verbose and descriptive code can improve  
maintainability.