fsa.addFinal(2); fsa.addTrans( 0, 'a', 1 ); fsa.addTrans( 1, 'b', 1 ); fsa.addTrans( 1, 'c', 2 ); fsa.addTrans( 2, 'd', 0 );
It is easy to implement automata with this table-driven framework. All you need to do is call methods to set up the tables. You could even have the program query the user about the transitions and final states, or read this information from a text file. (This would make a good programming exercise.) Better yet, the program could ask the user for a regular expression and then compile it into table entries. (This would be a very challenging programming exercise.)
However, in practice, for most string recognition tasks you should use the regular expression classes that come with Java. See the following chapters. (These classes themselves were almost certainly written using a table-driven approach.)
If you wish to implement a transducer, or deal with input other than character strings, the table-driven approach may be awkward to use. The type of implementation explained in sections two and three may be better.
A way to deal with these difficulties is to
use features of object oriented programming.
The table object would contain transition objects
(complete with transducer methods), indexed by state
and input objects.
But for many problems, simple automata are all
you need, and simple programs can easily implement them.
(Though Question: ) Could a one-character pushback automaton be implemented in table-driven fashion?