• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

State Design Pattern

 
Ranch Hand
Posts: 74
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
I am trying to evaluate the tradeoff between the traditional procedural type of state machine implementation vs. OO state machine implementation.
While the OO state pattern is more elegant(better abstraction on what needs to be done for each state) and easier for state classes to be reused, the drawback I see is that the OO way could potentially create/destroy way more objects (Performance!) than the traditional way.
e.g.
Traditional way:
class State {
boolean aReady;
boolean bReady;
boolean cReady;
}
void processEvent(State st) {
if (st.aReady && st.bReady && cReady)
// handle logic
else if (st.aReady && st.bReady && !cReady)
// handle logic
... etc
}
- Here, the logic of processEvent could be messy but you would only have one state object at runtime.
OO state machine:
class A_B_C_State implements State {
public State processEvent();
}
class A_B_NC_State implements State {
public State processEvent();
}
class A_NB_C_State implements State {
public State processEvent();
}
class A_NB_NC_State implements State {
public State processEvent();
}
...etc.
Here, there are 9 classes, each time you change state, a new state object needs to be instantiated and the old state object garbage collected. Although code structure is more elegant, performance hit is huge (esp in a server runtime environment with state changing for each client request).
I would greatly appreciate any inputs or pointers to documents about how to achieve a good balance between them.
Thanks
 
author
Posts: 799
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Usually there is only one instance of each concrete state class.
I've done 'em both ways. I typically won't bother using the objects-as-states pattern until things become a little unwieldy (or if things keep changing).
This article contains a discussion of the three-level FSM state machine pattern, which can be either overkill or extremely necessary: http://www.objectmentor.com/resources/articles/plop96ax.pdf (further down)
Instead of coding it yourself, consider a code generator; there are a handful of tools out there that will take a state machine in table form and generate all the necessary classes.
-Jeff-
[ March 03, 2004: Message edited by: Jeff Langr ]
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Additionally you need to be aware of the fact that with modern garbage collectors, short-lived objects are quite cheap.
With other words, I wouldn't expect it to be a problem. But if in doubt, try it! Shouldn't be too hard to come up with a benchmark.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic