[design patterns] de state machine

[Alarmnummer]

Voor een applicatie waar ik op dit moment mee bezig ben, heb ik een zwaar redeneer proces op een aparte thread lopen om de gui te ontlasten (anders blijft die helemaal stil staan). Daarna moet de thread ook weer contact op kunnen nemen met de gui om vragen te laten beantwoorden. Tijdens dit beantwoorden kan de gebruiker er oa voor kiezen om een andere sessie te beginnen, om een andere vraag opnieuw te beantwoorden, of om de redeneer sessie gewoon te laten stoppen. Tijdens het evalueren kunnen er fouten optreden (bv een rekenkundige fout of een database fout) en dezen moeten ook afgehandeld worden. Zoals je ziet heb je een groot scala aan mogelijkheden en dit zijn ze nog niet eens allemaal.

Ik heb 1 1/2 jaar geleden ook eens een oplossing voor gemaakt, maar ik was er eigelijk nooit tevreden over. Ik heb daar in de tussentijd veel over nagedacht hoe ik voor dit soort problemen (een probleem met een hele lading toestanden en toestandovergangen) een sluitende oplossing kon vinden.

Het ontwerp dat ik er voor heb gebruikt vond ik zelf eigelijk zeer ellegant. Ik heb op basis van een toestandsdiagram alle toestanden en alle events hiervoor geschreven vb:

Java:

public class BeginEngineState implements EngineState {

    private static BeginEngineState s_instance = new BeginEngineState();

    public static BeginEngineState getInstance() {
        return s_instance;
    }

    private BeginEngineState() {
    }

    public BeginEngineState reinit(){
        return BeginEngineState.getInstance();
    }

    public RunningEngineState start() {
        return RunningEngineState.getInstance();
    }

    public void accepts(EngineStateVisitor v) {
        v.visit(this);
    }

    public String toString() {
        return "begin";
    }
}

public class StartEvent extends EngineEvent {

    public StartEvent(EngineManager manager) {
        super(manager);
    }
}

Je kan nu vanaf de starttoestand, alleen in de running toestand komen, of je kan gereinitialiseerd worden. Door op deze manier te werken, kan ik garanderen dat je nooit in een verkeerde toestand kan komen. Daarnaast heb ik een object (de wrapper om de current state heen) gemaakt dat in zich een bepaalde toestand heeft, en voor ieder toestandsovergang een methode. Hij controleert eerst of je wel in de juiste toestand zit en stelt daarna de nieuwe toestand in (en is ook nog even zo vriendelijk om wat events te versturen naar listeners zodat de gui leuk kan reageren op de events).

Java:

public void start() {
        if (!(_state instanceof BeginEngineState))
            throw new EngineStateException(BeginEngineState.getInstance(), _state);

        _state = ((BeginEngineState) _state).start();

        //stuur aan alle luisteraars het nieuwe event
        StartEvent startEvent = new StartEvent(_manager);
        for (Iterator<EngineListener> itt = _listenerList.iterator(); itt.hasNext();) {
            itt.next().start(startEvent);
        }
    }

Ik was eigelijk wel erg tevreden over dit ontwerp omdat ik nu eindelijk eens een sluitende oplossing had voor iedere toestand waarin de engine kan verkeren. Ik wist gewoon dat hiervoor wel ergens een design pattern voor moest bestaan. De 'State' design pattern lijkt hier wel een beetje op, maar deze had zich niet zozeer bezig met de toestandsovergangen, en deze doet dat wel.

Ik was gisteravond even aan het bladeren in thinking in patterns van Bruce Eckel, en zag daar ineens de State Machine design pattern staan.. en ik had zoiets van tjakkaa... dat is hem.. Ik raad dus iedereen aan om eens wat te gaan lezen over het state machine design pattern... echt een geweldige design pattern waarmee je inzicht krijgt en houdt in een systeem vol toestandsovergangen.

[ Voor 11% gewijzigd door Alarmnummer op 05-08-2003 12:02 ]

[farlane]

Alarmnummer schreef wat over een statemachine:

Ziet er goed uit. Voor het type software dat ik schrijf heb ik vaak statemachines nodig, en ik heb dit tot nu toe nog niet echt goed kunnen combineren met OO, je komt dan altijd weer uit op een grote switch. ( Op meerde plaatsen in je app als het ff tegenzit )

Zal eens wat meer verdiepen in deze. ( En je visitor pattern )

Ik was gisteravond even aan het bladeren in thinking in patterns van Bruce Eckel, en zag daar ineens de State Machine design pattern staan..

Is dat boek nou al eens af of niet ? Die Eckel is een fijne man, maar ik moet al weet ik niet hoe lang wachten op deze en Vol2 van Thinking in C++.

[whoami]

farlane schreef op 05 August 2003 @ 11:38:
[...]


Ziet er goed uit. Voor het type software dat ik schrijf heb ik vaak statemachines nodig, en ik heb dit tot nu toe nog niet echt goed kunnen combineren met OO, je komt dan altijd weer uit op een grote switch. ( Op meerde plaatsen in je app als het ff tegenzit )

Ik weet natuurlijk het doel en design van je applicatie niet, maar als je veel gebruik moet maken van switches enzo, is het dan geen idee om het strategy design pattern te gebruiken?

[Alarmnummer]

farlane schreef op 05 August 2003 @ 11:38:
Ziet er goed uit. Voor het type software dat ik schrijf heb ik vaak statemachines nodig, en ik heb dit tot nu toe nog niet echt goed kunnen combineren met OO, je komt dan altijd weer uit op een grote switch. ( Op meerde plaatsen in je app als het ff tegenzit )

Klinkt eng Een van de hoofd oo regels is 'encapsulate what changes'. Aangezien die state het gene is dat veranderd, zou ik dat onderbrengen in een object. En zo gauw je een object te pakken hebt, kan je er ook polymorfisme en andere leuke oo grappen.

Is dat boek nou al eens af of niet ? Die Eckel is een fijne man, maar ik moet al weet ik niet hoe lang wachten op deze en Vol2 van Thinking in C++.

Het boek is nog niet af. Hij spring nog enorm van de hak op de tak dus het leest niet altijd even makkelijk. En verder geeft hij ook te veel aandacht aan problemen waar al lang een oplossing voor beschikbaar is, zoals bv zijn eigen versie van unit-testen. Misschien dat dit komt omdat hij al zo lang bezig is met dat boek, maar je begint regelmatig snel door te bladeren.

Als ik je nog iets mag aanraden, dan raad ik je deze aan:
Design Patterns Explained: A New Perspective on Object-Oriented Design Dit boek is imho een stuk minder droog dan het GoF boek, en je gaat echt op een andere manier tegen oo design aankijken. Echt een dikke aanrader.

[farlane]

whoami schreef op 05 August 2003 @ 11:44:
[...]
Ik weet natuurlijk het doel en design van je applicatie niet, maar als je veel gebruik moet maken van switches enzo, is het dan geen idee om het strategy design pattern te gebruiken?

Die kan idd worden toegepast waar er 'geswitched' moet worden tussen veschillende 'bewerkingen'.

Maar de meest vervelende ( lees langste ) switches treden iha op bij statemachines. Een switch met 20 states ( labels ) is al best vervelend om te lezen, laat staan onderhouden.

[farlane]

Alarmnummer schreef op 05 augustus 2003 @ 11:50:
Klinkt eng

Is het ook. Onderhouden wordt na verloop van tijd een ramp omdat een nieuwe state altijd betekent dat je op al die 'switch' plekken je code doormoet.

Het boek is nog niet af. Hij spring nog enorm van de hak op de tak dus het leest niet altijd even makkelijk.

Volgens mij is die man met veel te veel dingen tegelijk bezig

Als ik je nog iets mag aanraden, dan raad ik je deze aan: ....

Thx, ga er direct ff naartoe
BTW, heb je die zelf ook ?

[edit]
Spelvauten

[ Voor 7% gewijzigd door farlane op 05-08-2003 12:11 ]

[Alarmnummer]

farlane schreef op 05 August 2003 @ 11:58:
Is het ook. Onderhouden wordt na verloop van tijd een ramp omdat een nieuwe state altijd betekend dat je op al die 'switch' plekken je code doormoet.

' do it once.. and once only' en 'replace conditionals by polymorfism' - martin fowler - refactoring.

Thx, ga er direct ff naartoe
BTW, heb je die zelf ook ?

Ik heb hem zelf ook...

[ Voor 12% gewijzigd door Alarmnummer op 05-08-2003 12:06 ]

[Alarmnummer]

Ik heb nog even wat aanpassingen gemaakt:

Java:

public abstract class EngineState {

    public final static EngineState BEGIN = new BeginEngineState();
    public final static EngineState FINISHED = new FinishedEngineState();
    public final static EngineState STOPPED = new StoppedEngineState();
    public final static EngineState READY_TO_RUN = new ReadyToRunEngineState();
    public final static EngineState RUNNING = new RunningEngineState();
    public final static EngineState ERROR = new ErrorEngineState();
    public final static EngineState WAITING_FOR_ANSWERS = new WaitingForAnswersEngineState();

    public abstract EngineState next(EngineEvent e);

    private static class BeginEngineState extends EngineState {
        public EngineState next(EngineEvent e) {
            Assert.assertNotNull(e);

            if (e instanceof InitEvent)
                return READY_TO_RUN;

            throw new EngineStateException(this,e);
        }
        public String toString(){
            return "begin";
        }
    }

    private static class FinishedEngineState extends EngineState {
        public EngineState next(EngineEvent e) {
            Assert.assertNotNull(e);

            if (e instanceof AnswerChangedEvent)
                return RUNNING;

            if (e instanceof InitEvent)
                return READY_TO_RUN;

            throw new EngineStateException(this,e);
        }
        public String toString(){
            return "finished";
        }
    }

    private static class ReadyToRunEngineState extends EngineState {
        public EngineState next(EngineEvent e) {
            Assert.assertNotNull(e);

            if (e instanceof StartEvent)
                return RUNNING;

            if (e instanceof InitEvent)
                return this;

            throw new EngineStateException(this,e);
        }
        public String toString(){
            return "readyToRun";
        }
    }

    private static class StoppedEngineState extends EngineState {
        public EngineState next(EngineEvent e) {
            Assert.assertNotNull(e);

            if (e instanceof InitEvent)
                return READY_TO_RUN;

            throw new EngineStateException(this,e);
        }
        public String toString(){
            return "stopped";
        }
    }

    private static class RunningEngineState extends EngineState {
        public EngineState next(EngineEvent e) {
            Assert.assertNotNull(e);

            if (e instanceof AnswerFoundInMemoryEvent)
                return this;

            if (e instanceof ErrorEvent)
                return ERROR;

            if (e instanceof FinishEvent)
                return FINISHED;

            if (e instanceof AnswerNeededEvent)
                return WAITING_FOR_ANSWERS;

            throw new EngineStateException(this,e);
        }
        public String toString(){
            return "running";
        }
    }

    private static class ErrorEngineState extends EngineState {
        public EngineState next(EngineEvent e) {
            Assert.assertNotNull(e);

            if (e instanceof InitEvent)
                return READY_TO_RUN;

            throw new EngineStateException(this,e);
        }
        public String toString(){
            return "error";
        }
    }

    private static class WaitingForAnswersEngineState extends EngineState {
        public EngineState next(EngineEvent e) {
            Assert.assertNotNull(e);

            if (e instanceof InitEvent)
                return READY_TO_RUN;

            if (e instanceof StopEvent)
                return STOPPED;

            if (e instanceof AnswerAvailableEvent)
                return RUNNING;

            if (e instanceof AnswerChangedEvent)
                return RUNNING;

            throw new EngineStateException(this,e);
        }
        public String toString(){
            return "waitingForAnswer";
        }
    }
}

public class EngineStateMachine {

    private EngineState _state = EngineState.BEGIN;
    private List<EngineListener> _listenerList = new LinkedList<EngineListener>();

    public EngineStateMachine() {
    }

    public void addListener(EngineListener l) {
        Assert.assertNotNull(l);
        _listenerList.add(l);
    }

    public void next(EngineEvent e){
        Assert.assertNotNull(e);
        System.out.println("current-state: "+_state);
        System.out.println("e: "+e.getClass());
        System.out.println();
        _state = _state.next(e);
        e.accepts(new EventDispatcher());
    }

    private class EventDispatcher implements EngineEventVisitor{

        public void visit(AnswerAvailableEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().answerAvailable(e);
        }

        public void visit(AnswerChangedEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().answerChanged(e);
        }

        public void visit(AnswerFoundInMemoryEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().answerFoundInMemory(e);
        }

        public void visit(AnswerNeededEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().answerNeeded(e);
        }

        public void visit(ErrorEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().errorEncountered(e);
        }

        public void visit(FinishEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().finish(e);
        }

        public void visit(InitEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().init(e);
        }

        public void visit(StartEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().start(e);
        }

        public void visit(StopEvent e) {
            for(Iterator<EngineListener> itt = _listenerList.iterator();itt.hasNext();)
                itt.next().stopped(e);
        }
    }


}

Die visitor gaat er denk ik nog weer uit en breng het event versturen onder bij de events zelf.

[ Voor 6% gewijzigd door Alarmnummer op 06-08-2003 10:11 ]

[alienfruit]

Alarmnummer, mag ik jou vragen waar GoF voor staat? Ik kan niet zo snel uit deze afkorting herleiden wat de (mogelijke) titel van het boek moet zijn.

[gorgi_19]

alienfruit schreef op 06 augustus 2003 @ 14:14:
Alarmnummer, mag ik jou vragen waar GoF voor staat? Ik kan niet zo snel uit deze afkorting herleiden wat de (mogelijke) titel van het boek moet zijn.

http://www.amazon.com/exe...7776996-4699329?vi=glance

GoF = Gang of Four, waarmee bedoeld wordt de 4 auteurs van het boek Design Patterns.

[ Voor 12% gewijzigd door gorgi_19 op 06-08-2003 14:15 ]

[alienfruit]

Thanks. Gorgi_19 ik ging er vanuit dat het een titel van een boek was ipv zoiets dergelijks. Maar dit boek Design Patterns heb ik wel.

[farlane]

Alarmnummer schreef op 06 August 2003 @ 10:09 een bunch code:

Was zelf even aan het stoeien met dit verhaal, maar op een of andere manier staat die rtti me tegen.

Bovendien is dit eigenlijk weer een verborgen switch.

Vraag me af of er geen elegante methode is om dit zonder te doen ?

[edit]

Nog een vraagje ... waar bevinden zich bij jou de voorwaarden of een state in een bepaalde andere state mag overgaan ? Zou je die in de state objecten zelf onderbrengen ( wat misschien wel weer betekent dat de coupling tussen de state objecten wordt vergroot ), of gebruik je daarvoor een ander object ?

[ Voor 31% gewijzigd door farlane op 06-08-2003 20:24 ]

[Alarmnummer]

farlane schreef op 06 augustus 2003 @ 20:20:
[...]


Was zelf even aan het stoeien met dit verhaal, maar op een of andere manier staat die rtti me tegen.

Je bedoelt die visitor?

Bovendien is dit eigenlijk weer een verborgen switch.

Switches zijn niet zo erg. Als je bij een switch compile time kan garanderen dat je voor iedere optie ook een case hebt, dan zie ik eerlijk gezegd geen verschil. En ik heb er verder een enorme hekel aan om functionaliteit onder te brengen die eigelijk niet echt bij het object thuis hoort omdat die functionaliteit gegroepeerd bij een andere subsysteem had moeten zitten. Ik vind het dus vervelender dat functionaliteit ligt verspreid over het systeem dan om een switch te gebruiken. Ik gebruik dus veel visitors om functionaliteit te groeperen binnen 1 object, zoals dit gebeurt bij die eventverstuurder.

Vraag me af of er geen elegante methode is om dit zonder te doen ?

Er zijn er genoeg Als java nou eens echte multidispatch had, dan had je niet hoeven te emmeren met een visitor en verder kan je het event versturen ook onderbrengen bij de event. In dit geval zou dat niet erg zijn, omdat events en listeners bij elkaar horende functionaliteit is, en de cohesie van je object dan ook hoog blijft.

Nog een vraagje ... waar bevinden zich bij jou de voorwaarden of een state in een bepaalde andere state mag overgaan ? Zou je die in de state objecten zelf onderbrengen ( wat misschien wel weer betekent dat de coupling tussen de state objecten wordt vergroot ), of gebruik je daarvoor een ander object ?

Een state mag in principe altijd in een andere state overgaan, als het event dat de overgang tot stand brengt, ook correct is. Als je bv kijkt bij de FinishedState, dan kan je daar nooit een StopEvent op los laten, omdat die state dat niet aankan (je krijgt dan een StateException). Op deze manier kan ik garanderen dat ik nooit een verkeerde toestandsovergang kan krijgen.

[farlane]

Misschien ook nog wel een leuk artikel over de state machine:

http://liemur.co.uk/Articles/FiniteStateMachine.html

[Alarmnummer]

Ik zal het artikel even doorlezen en ik heb de site meteen toegevoegd aan mijn 'niet verliezen' lijst, thanx.