Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #2605

Re: Enums: Properties vs. Methods

Show key headers only | View raw

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() {
         }
     }
}

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-29 08:18 -0700
  Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 11:47 -0400
    Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-30 20:00 +0200
      Re: Enums: Properties vs. Methods Lew <lew@lewscanon.com> - 2011-03-30 13:17 -0700
        Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-31 00:48 -0700
          Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 08:41 -0400
            Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-31 08:26 -0700
              Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 22:16 -0400
                Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-04-02 11:56 +0200
                Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-04-02 10:29 -0400
                Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-04-03 13:14 +0200
  Re: Enums: Properties vs. Methods markspace <-@.> - 2011-03-29 09:26 -0700
    Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-30 20:06 +0200
      Re: Enums: Properties vs. Methods markspace <-@.> - 2011-03-30 12:40 -0700
        Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-31 00:38 -0700
  Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-29 19:03 +0200
    Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-29 19:04 +0200
  Re: Enums: Properties vs. Methods Roedy Green <see_website@mindprod.com.invalid> - 2011-03-29 12:49 -0700
  Re: Enums: Properties vs. Methods Roedy Green <see_website@mindprod.com.invalid> - 2011-03-29 12:52 -0700
    Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-29 22:45 +0200
      Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 17:08 -0400
        Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-29 23:25 +0200
          Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 19:05 -0400
            Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-29 19:40 -0400
              Re: Enums: Properties vs. Methods Robert Klemme <shortcutter@googlemail.com> - 2011-03-31 02:57 -0700
                Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 08:52 -0400
                Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 08:54 -0400
            Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-30 18:40 +0200
              Re: Enums: Properties vs. Methods Lew <lew@lewscanon.com> - 2011-03-30 10:33 -0700
                Re: Enums: Properties vs. Methods Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2011-03-30 20:43 +0200
                Re: Enums: Properties vs. Methods Lew <lew@lewscanon.com> - 2011-03-30 13:20 -0700
                Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-03-31 08:55 -0400
  Re: Enums: Properties vs. Methods Wanja Gayk <brixomatic@yahoo.com> - 2011-04-02 11:23 +0200
    Re: Enums: Properties vs. Methods Lew <noone@lewscanon.com> - 2011-04-02 10:36 -0400
      Re: Enums: Properties vs. Methods Wanja Gayk <brixomatic@yahoo.com> - 2011-04-02 21:20 +0200

csiph-web