Re: Re: Decision Trees and the Strategy Design Pattern

[djantzen]

State is definitely an important aspect of this, so I like the idea of maintaining that as a separate entity. I especially like the ability to store past states, as in some cases it may be necessary to step backward in the history of an entity in the system. I've been hoping to avoid hardcoding specific subroutines like send_ticket_to_supervisor, but on the other hand, the fact that those are in a distinct "logic" module means that different behavior could be achieved by overriding those methods or writing a new module.

Thanks for your thoughts pdcawley :)

[pdcawley]

The thing is, at some point you're going to have to code the 'what happens next' process. It may make sense though to add a do_next_thing method to your state class and then write:

sub TicketState::New::next_action { 'send_ticket_to_supervisor' }

sub TicketState::Pending::next_action { 'send_to_editorial_group' }

sub TicketState::do_next_thing {
    my $self = shift;
    my $action = $self->next_action;
    $self->$action(@_);
}

By doing things this way you get to give meaningful names to the individual actions handled by a state, but still have a simple dispatch system that simply calls $ticket->do_next_action on every ticket it dispatches.

If you're using the state simply to control the flow of an object through a system and you've not got other state dependent behaviour then you can probably get away with having a single state class and a handy dandy config file but I don't think I'd recommend starting out with one.