finite state machine with enum

A

andijcr

hi all
i have a byte stream that has to be decoded in a list of simple
containers - basically I do a translation from serial to parallel.
The implementation I'm using now has this form:

public class RawProtocol{

private long millis=/*some initialization procedure*/;
public RawProtocol(InputStream inputStream, OutputStream
outputStream){
this.bq=new LinkedBlockingQueue<Byte>();
this.is=inputStream;
this.os=outputStream;
}

public RawData getRawData() {
Byte temp;
do{
if((temp=bq.poll())!=null)
state=state.exec(temp);
else
return null;
}while(state!=Mlsm.START);
/*...
return a deserialized packet
... */
}

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;
}
},
TIME_RED {
public Mlsm exec(byte value){
pushValue(value); //this is a value and should be
treated in another way
return VALUE_RED;
}
},
VALUE_RED {
public Mlsm exec(byte stop){
switch (stop){
case stopByte:
commit(); //the sequence (time - value) is well
formed and can be saved in a packet
return START;
default: return GARBAGE;
}
}
},
GARBAGE {
public Mlsm exec(byte grbg){
switch (grbg){
case stopByte: return START;
default: return this;
}
}
};

public abstract Mlsm exec(byte b);
}
}

the machine is activated through getRawData, which makes it perform a
complete cycle to produce a single packet of formatted data

the initial idea to use a state machine implemented as an inner class
was to:
- bring order in the code
- to take advantage of some time-dependent data (millis) managed by
the outer class RawProtocol (most important)

However enum is defined as static, and this disables access to the
fields of rawprotocol.
The main issue then is: how can I make a private field (not static) of
RawProtocol accessible (read at least) to Mlsm, in an elegant way and
java-esque way?

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?

The first ideas I had (but I would like to avoid) were to delegate to
the state machine only the definition of the sequence of operations,
implementing the same operations as methods of an instance of
RawProtocol;
Or convert `enum Mlsm` in an inner `class Mlsm` that acts as enum
(rewriting all the methods that would otherwise be handled
automatically by the compiler) except for the fact to be not static.

Or convert enum Mlsm in an inner class that acts as Mlsm enum (then
writing all the methods that would otherwise be handled automatically
by the compiler) except that it is not static.

other ideas - standard methodologies to resolve the issue?
 
L

Lew

andijcr said:
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.
 
T

Tom Anderson

i have a byte stream that has to be decoded in a list of simple
containers - basically I do a translation from serial to parallel. The
implementation I'm using now has this form:

public class RawProtocol{

private long millis=/*some initialization procedure*/;
public RawProtocol(InputStream inputStream, OutputStream
outputStream){
this.bq=new LinkedBlockingQueue<Byte>();
this.is=inputStream;
this.os=outputStream;
}

public RawData getRawData() {
Byte temp;
do{
if((temp=bq.poll())!=null)
state=state.exec(temp);
else
return null;
}while(state!=Mlsm.START);
/*...
return a deserialized packet
... */
}

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;
}
},
TIME_RED {
public Mlsm exec(byte value){
pushValue(value); //this is a value and should be
treated in another way
return VALUE_RED;
}
},
VALUE_RED {
public Mlsm exec(byte stop){
switch (stop){
case stopByte:
commit(); //the sequence (time - value) is well
formed and can be saved in a packet
return START;
default: return GARBAGE;
}
}
},
GARBAGE {
public Mlsm exec(byte grbg){
switch (grbg){
case stopByte: return START;
default: return this;
}
}
};

public abstract Mlsm exec(byte b);
}
}

the machine is activated through getRawData, which makes it perform a
complete cycle to produce a single packet of formatted data

the initial idea to use a state machine implemented as an inner class
was to:
- bring order in the code

Seriously? You think that's more ordered than:

DataInputStream in;
while (true) {
pushTime(in.readByte());
pushValue(in.readByte());
byte stop = in.readByte();
if (stop == stopByte) {
commit();
}
else {
while ((stop = in.readByte()) != stopByte);
}
}

?

If what you've posted is really what you're doing, and not a huge
simplification of what you're actually doing, then you've massively
overcomplicated this.
- to take advantage of some time-dependent data (millis) managed by the
outer class RawProtocol (most important)

I don't see why you couldn't do that with the above loop.

tom
 
A

andijcr

Seriously? You think that's more ordered than:

DataInputStream in;
while (true) {
        pushTime(in.readByte());
        pushValue(in.readByte());
        byte stop = in.readByte();
        if (stop == stopByte) {
                commit();
        }
        else {
                while ((stop = in.readByte()) != stopByte);
        }

}

?

If what you've posted is really what you're doing, and not a huge
simplification of what you're actually doing, then you've massively
overcomplicated this.


I don't see why you couldn't do that with the above loop.

tom

the snippet is a simplification of the real code, tough it is not so
much more complicated. Here i made the decision to use a simple
implementation of a state machine, instead of a sequence of methods,
for the elasticity i can obtain in the interpretation of the not-so-
stable underlying protocol.
 
T

Tom Anderson

the snippet is a simplification of the real code, tough it is not so
much more complicated. Here i made the decision to use a simple
implementation of a state machine, instead of a sequence of methods, for
the elasticity i can obtain in the interpretation of the not-so- stable
underlying protocol.

Do you configure the state machine from a file or similar? If not, it's no
more plastic than code.

People have this idea that once code is written, it's hard to change. This
is wrong.

tom
 
A

andijcr

Pass it as an argument to the enum 'exec' method.

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.
 
D

Daniel Pitts

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);
}
}
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,995
Messages
2,570,226
Members
46,815
Latest member
treekmostly22

Latest Threads

Top