Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: markspace <-@.> Newsgroups: comp.lang.java.programmer Subject: Re: Enums: Properties vs. Methods Date: Wed, 30 Mar 2011 12:40:34 -0700 Organization: A noiseless patient Spider Lines: 248 Message-ID: References: <2f38bb8e-9a8d-4464-ad3d-b9ce0b557219@e21g2000yqe.googlegroups.com> <8vh9p1FikeU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Wed, 30 Mar 2011 19:40:38 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="GX7JEK/zO1crY1n0kxPQzA"; logging-data="1877"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+eed3BjxOvBv8ZEdBnm7+fh75X3TdEk8=" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 In-Reply-To: <8vh9p1FikeU1@mid.individual.net> Cancel-Lock: sha1:23YlI0P0CS75xVgZcz0j7L5SN94= Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:2605 On 3/30/2011 11:06 AM, Robert Klemme wrote: > Actually I always have a hard time distinguishing those two patterns: > IMHO they are pretty much identical at the core, They're very different. State is for implementing state machines. Strategy is for extensibility. The biggest difference, to me, is that if I were implementing a State pattern, I'd treat the State class as an implementation detail and keep it and its children private. Whereas for Strategy having a public Strategy interface/class is the whole point. > See https://gist.github.com/892503#file_valve.java This really isn't either State or Strategy. It's just an enum with some properties. I think you mean it to be a State, so let's start there. State has defined transitions from one state to another. That each state also might have a defined properties is almost incidental. Let me try to find a better example, something that's a well known state machine: opening up my TCP book (Comer) I see that he defines a TCP connection to have the following states: LISTEN, SYNSENT, SYNRCVD, ESTABLISHED, FINWAIT1, FINWAIT2, LASTACK, CLOSEWAIT, TIMEWAIT, CLOSING, CLOSED, and FREE. These state transition depending on whether an SYN, RESET or FIN has been received, whether the user calls close(), and some internal timers. I don't want to do the whole state machine (it's complicated) so let's just try part of it. The first bit is that the internal state of a TCP connection is an implementation detail and should not be public. This is very different from Strategy! So starting from ESTABLISHED, if a fin is recieved, it goes to the CLOSEWAIT state. If a syn is received, it's an error and we send a reset and abort the connection. If a reset is received, we abort the connection. Here I'm just going straight to the CLOSED state after aborting the connection, although Comer doesn't mention this. From CLOSEWAIT, we wait for the application to close the connection, then send a fin and go to LASTACK. Normally I think there's some sending of final data here too. From LASTACK, if we get a syn, we send a reset and abort the connection. If we get a reset, we abort the connection. It seems to me we should be waiting for an ack to our fin, but Comer doesn't mention it. From CLOSED, we are quiescent, although if we get any actual data on a closed channel we should sent a reset (not shown). Note that Comer doesn't always explicitly define each state transition. Those that I couldn't find I just let them throw an error. This might be wrong, but I felt was safest. Note also that the State pattern "Context" here is called TcpConnectionTest. Each state is discreet and does its own thing. It's not affected by other states, the code is nicely encapsulated, and it's easy to extend by adding more states and more transitions. Each state here has a reference to its context (TcpConnectionTest). The state drives the processing on the context, and also sets the next state when a transition is called for. The context itself doesn't really know how states progress, but it does provide methods for the states to call when they need something done. This is normal for the State pattern, afaik. Also, I'm using inner classes here, but that's only for a usenet example. I could have used an implicit point to the enclosing class (TcpConnectionTest) but that's not part of the State pattern. So I use static inner classes and I pass a reference to the context via each constructor, which is part of the State pattern. I'd suggest you get a good introductory book to design patterns, such as Head First Design Patterns. /* Copyright 2011 Brenden Towey. All rights reserved. */ package test; /** * * @author Brenden Towey */ public class TcpConnectionTest { private TcpState state; public TcpConnectionTest() { state = new Established( this ); } public void reset() { state.reset(); } public void close() { state.close(); } public void fin() { state.fin(); } private void sendReset() { System.out.println("Reset"); } private void doAbort() { System.out.println("Abort"); } private void sendFin() { System.out.println("Fin"); } private static abstract class TcpState { final TcpConnectionTest connection; public TcpState(TcpConnectionTest connection) { this.connection = connection; } abstract void fin(); abstract void syn(); abstract void close(); abstract void reset(); } private static class Established extends TcpState { public Established( TcpConnectionTest con ) { super( con ); } @Override void fin() { connection.state = new CloseWait( connection ); } @Override void syn() { connection.sendReset(); connection.doAbort(); connection.state = new Closed( connection ); } @Override void close() { throw new UnsupportedOperationException("Not supported yet."); } @Override void reset() { connection.doAbort(); connection.state = new Closed( connection ); } } private static class CloseWait extends TcpState { public CloseWait(TcpConnectionTest connection) { super( connection ); } @Override void fin() { throw new UnsupportedOperationException("Not supported yet."); } @Override void syn() { throw new UnsupportedOperationException("Not supported yet."); } @Override void close() { connection.sendFin(); connection.state = new LastAck( connection ); } @Override void reset() { throw new UnsupportedOperationException("Not supported yet."); } } private static class LastAck extends TcpState { public LastAck(TcpConnectionTest connection) { super( connection ); } @Override void fin() { throw new UnsupportedOperationException("Not supported yet."); } @Override void syn() { connection.sendReset(); connection.doAbort(); connection.state = new Closed( connection ); } @Override void close() { throw new UnsupportedOperationException("Not supported yet."); } @Override void reset() { connection.doAbort(); connection.state = new Closed( connection ); } } private static class Closed extends TcpState { public Closed(TcpConnectionTest connection) { super(connection); } @Override void fin() { } @Override void syn() { } @Override void close() { } @Override void reset() { } } }