finite state machine with enum
in [Java Help]
|
From: andijcr on 10 Feb 2010 18:12 On 10 Feb, 19:15, Lew <no...(a)lewscanon.com> wrote: > andijcr wrote: > > The main issue then is: how can I make a field private (not static) > > RawProtocol accessible (for reading at least) to Mlsm, in an elegant > > way and to objects? > > Pass it as an argument to the enum 'exec' method. > > -- > Lew I don't really like this solution - the field in the real code is needed only in one of the eight states (while other states could in the future require access to other fields). My point here was to find if an elegant implementation is possible - which seems impossible in the way i imagined. Eventually my current solution works and is object-oriented. thanks for your interest anyway.
From: Roedy Green on 11 Feb 2010 19:36 On Wed, 10 Feb 2010 09:53:28 -0800 (PST), andijcr <andij.cr(a)gmail.com> wrote, quoted or indirectly quoted someone who said : > enum Mlsm{ //stands for my little state machine > > START { > public Mlsm exec(byte time){ > pushTime(time); //this byte represents a time and >should be treated in a way > return TIME_RED; I have written quite a few of theses things for JDisplay to colourise various sorts of text, e.g. Java, HTML, manifests, bat files. See https://wush.net/websvn/mindprod/listing.php?repname=mindprod&path=%2Fcom%2Fmindprod%2Fjprep%2F -- Roedy Green Canadian Mind Products http://mindprod.com Every compilable program in a sense works. The problem is with your unrealistic expections on what it will do.
From: Daniel Pitts on 12 Feb 2010 18:05
On 2/10/2010 3:12 PM, andijcr wrote: > On 10 Feb, 19:15, Lew<no...(a)lewscanon.com> wrote: >> andijcr wrote: >>> The main issue then is: how can I make a field private (not static) >>> RawProtocol accessible (for reading at least) to Mlsm, in an elegant >>> way and to objects? >> >> Pass it as an argument to the enum 'exec' method. >> >> -- >> Lew > > I don't really like this solution - the field in the real code is > needed only in one of the eight states (while other states could in > the future require access to other fields). > My point here was to find if an elegant implementation is possible - > which seems impossible in the way i imagined. > Eventually my current solution works and is object-oriented. thanks > for your interest anyway. Using similar to the flyweight pattern. I often have the following design: public class State { private int someStateField; private String someOtherStateField; StateNode node = StateNode.A; public void transition(Object input) { node.transition(this, input); } private enum StateNode { A { public void transition(State state, Object input) { ... }}, B { public void transition(State state, Object input) { ... }}, C { public void transition(State state, Object input) { ... }}; public abstract void transition(State state, Object input); } } -- Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/> |