[...]

You ignored one particular property in your argumentation: Dependencies.

In a well designed OO application you have sub-systems which operate
relatively independent from other systems. Each sub-system is only
concerned with a relatively small aspect of the whole system's
operation. You might have thousands of classes in a large system, but
since each sub-system is manageable, you whole system is still manageable.

But, in the state pattern issue you end up with a boatload of classes
which only as a whole make up the state machine. They are not
independent. They are a big ball of mud. With each class (alias state)
which you add, you get number-of-events new possible (not necessarily
legal) state transitions, and you have to potentially revise
number-of-events times number-of-existing-states old possible (not
necessarily legal) state transitions.

When you maintain such a state machine you are presented with a list of
classes (in Java possibly as much files, if you use public classes).
That list does not give you any clue about the nature of the particular
state machine they form. You don't see the interaction, a core property
of a state machine, from the classes. One can argue that the state
pattern is not a good OO model of a state machine, since it neglects an
important property of the thing which it models. A consequence one can't
make up a (mental) 1:1 mapping of what one wants/needs to implement to
how and where it needs to be implemented. This makes maintenance harder.
And it gets harder with each additional state.

See above. Adding a state can potentially affect the whole state
machine, which is composed of all the existing state classes (plus a
context). Changing a state has the same effect.

/Thomas

Well, of course, as the amount of code (or equivalently up to linear factors --
one hopes!) the functionality increases, then one is always going to hit a
brick wall sooner or later.  I assume that the number of classes will scale
linearly with the amount of code.  For any "difficulty metric", that metric
will increase with the amount of code, and hence with the number of classes.
We all know and use techniques which -- we trust and believe -- will keep the
relationship sub-linear, but I doubt very much whether there can ever be a way
of making the relationship /flat/ (and if there is, then why not a way to make
the relationship negative -- so that the difficulty metric decreases as
complexity increases ?).

But still, I suspect that Thomas meant something much more specific about the
classes used in a State pattern.  That's what /I/ would have meant anyway.

If you try to implement a non-trivial state machine as an application of the
State Pattern, then you end up with large (by definition) numbers of very
closely related (by design) classes.   There may be little or no /formal/
coupling between them, but in fact they form a rat's nest of highly
interdependent cross references.  And you hit a comprehension barrier almost
immediately.

For instance modelling state transition graph of a simple network application
might give:
   Disconnected
   Connecting
   Connected
   Loggng In
   Logged In
   Loggin out
   Logged out
   Ready
   AwaitingResponse
   UnrecoverableError
and that might be perfectly feasible to implement with the State Pattern.  But
if it /is/ perfectly feasible, then the State Pattern isn't buying you a lot
compared with just embedding the knowledge of the current state (not "State")
into the code itself (or even into the /structure/ of the code).

But if the state mesh is complicated -- for instance even a simple lexical
analyser -- then the number of states, and the relationships between the
classes which implement them, become unmanageable.   Part of it is just the
difficulty of working with large state meshes by hand, but another part of it
is dealing with the /representation/ of that state mesh as classes.  Finding
names for them is a challenge all by itself.

As an example (not using the State Pattern but still with a hand-coded state
machine expressed using "normal" OO techniques rather than table-driven).  A
year or two ago I made the mistake of coding a tokeniser for a language (with
fairly simple syntax) by hand.  I represented each state as a method, the
current "state" was invoked for each input character, and as it executed it
would change the state and/or consume the input.  I'm fairly happy thinking in
terms of state machines (more so than most programmers), and that seemed a
natural way to express the solution.  It was (and is) a disaster.  I can hardly
modify it myself, and I doubt it anyone else would even be able to understand
it at all.  There are (only) about 40 states.   Some are quite simple
<inInteger>, <inMantissa>, <inString>, and so on.  They don't cause the
problems, it's the 30 or so more intricate states such as
<seenExponenetLetterAfterInteger>, <seenLeadingMinusInArray>,
<seenTrailingMinusAfterBinaryOperaror>, and the relationships between them,
that make the thing incomprehensible.

The language I was using allows me to refer to methods directly (as first class
values, assignable to a variable).  That representation would be impossible in
Java; the nearest equivalent would be an application of the State Pattern.  And
that also would be a disaster ;-)

   -- chris