On Dec 14, 2009, at 1:16 AM, Emmanuel Lecharny wrote:
Alan D. Cabrera a écrit :
On Dec 13, 2009, at 2:42 AM, Emmanuel LŽcharny wrote:
<snip/>
The key thing about state machines is that the states and the
transitions are known and fixed ahead of time. If this our state
of affairs, and I think that it is, then things are much more
simple and mentally tractable, i.e. there's no ad hoc filter
creation during protocol processing and much of the threading
issues in past entries on this thread disappear.
Generally speaking, when implementing a protocol, states and
transitions are very well known and static, so the SM approach
seems adequate.
Agreed, the SM approach should cover all cases; even the logging
case in your subsequent post.
So with that said, would it not make sense to have a set of fixed
filter chains w/ each chain representing a state rather than a
bucket of filters with each filter deciding the next filter to
execute?
Not necessarily, for three reasons :
1) if the chain is fixed at startup, you can't anymore inject a
LoggingFilter when the server is running. You can only activate or
desactivate it. Not that it's realy a big issue, but it may help in
some case (that also mean we have a way to control the execution.
JMX ?)
One normally doesn't turn on and off things like that on a per message
basis. What I mean by that is that each filter decides to do what it
needs to do. That includes logging. Constantly injecting logging
filters on an ad hoc basis is a very, very, poor practice.
2) Most important, if we don't have a clue about which is the next
filter in the chain, that leads to problem when debugging, as you
can't know which filter will be called. Ennoying
Sure you do. The chains are fixed. If you know what filter you are
and what state you're in you know what filter gets called next from
the perspective of the framework. From the perspective of the filter
you shouldn't care what's next, if you do then you've introduce a
brittle dependency. For me that;s usually a red flag that I haven't
thought through a design and it needs to be revisited.
3) Last, not least, we want to be able to call the next filter in
the middle of a processing :
messageReceived() {
do blah();
if ( condition ) {
do anotherBlah();
call Next filter();
} else {
do yetAnotherBlah();
call nextFilter();
}
do endingBlah();
}
That just tells me that you have mixed up two states into one and that
you need to expend a little more effort into your state machine design.
Not sure this is possible in another way than with those computed
nextFilter() inside the filters.
I agree but it's my contention that it's a bad practice that supports
an ill thought out protocol.
(well, t's always possible to express this with more transitions and
states, but t would be more complicated to write filters then...)
I'm looking at your messageReceived() method and am thinking that you
have provided me with a perfect example for state programming. Only
the original author of that method would know what's going on.
Regards,
Alan
