Algoritme voor keuzeboom

[Verwijderd]

Ik wil een vrij grote keuzeboom maken, daarvoor heb ik een algoritme nodig. Omdat ik op internet niet veel kon vinden ben ik zelf maar aan de slag gegaan, ik had daarbij 2 ideeen die ik in pseudo code heb opgesteld

idee #1

code:

keuzeBoom(boom)
{
   element = EERSTE;

   while ( element <> EIND )
   {
    switch ( element )
    {
       case EERSTE:
        switch (boom[EERSTE].data)
        {
           case ROOD:
            uitvoer( "Kleur = ROOD" );
            element = TWEEDE;
            break;

           case GEEL:
            uitvoer( "Kleur = GEEL" );
            element = TWEEDE;
            break;

           // Etcetera
    
       case TWEEDE:
        switch (boom[TWEEDE].data)
        {
           case VIERKANT:
            uitvoer( "Lichaam = VIERKANT" );
            element = LAATSTE;
            break;

           case ROND:
            uitvoer( "Lichaam = ROND" );
            element = LAATSTE;
            break;

           //etcetera
        }
       }
       case LAATSTE:
        //etcetera
    }
   }
}

idee #2

code:

keuzeBoom(boom)
{
   switch (boom[EERSTE].data)
   {
    case ROOD:
       uitvoer( "Kleur = ROOD" );
       bepaalLichaam( Boom );
       break;

    case GEEL:
       uitvoer( "Kleur = GEEL" );
       bepaalLichaam( Boom );
       break;

    // Etcetera
   }
}

bepaalLichaam(boom)
{
   switch (boom[EERSTE].data)
   {
    case ROOD:
       uitvoer( "Kleur = ROOD" );
       bepaalLichaam( Boom );
       break;

    case GEEL:
       uitvoer( "Kleur = GEEL" );
       bepaalLichaam( Boom );
       break;

    // Etcetera
   }
}

bepaalLichaam( Boom )
{
   switch (boom[TWEEDE].data)
   {
    case VIERKANT:
       uitvoer( "Lichaam = VIERKANT" );
       bepaalMateriaal( Boom );
       break;

    case ROND:
       uitvoer( "Lichaam = ROND" );
       bepaalMateriaal( Boom );
       break;

    //etcetera
   }
}

bepaalMateriaal( Boom )
{
   //etcetera
}

Heeft iemand een idee welke van deze twee opties de beste is of heeft men een betere oplossing?!?

[Janoz]

ZOu je mischien iets uitgebreider kunnen toe lichten wat je van plan bent? Wat houdt rond/vierkant en rood/geel, maar vooral eerste, tweede, laatste ed.

Daarnaast denk ik dat je een tikfoutje in je psuedo code gemaakt hebt aangezien je in je tweede stukje 2x dezelfde functie hebt.

Maar ben je nu de complete boom aan het uitwerken in de source?


_{[edit] Het foutje(?) zat in het tweede voorbeeld, niet in het eerste}

[Verwijderd]

Ik wil complexe data over een netwerk ontvangen, daarvoor gebruik ik een volgende structuur:

Frame:
[Kleur][Lichaam][Etc..]

Een voorbeeld van een frame kan dan zijn:
[ROOD][VIERKANT][Etc...]

Mijn programma moet dan deze data verwerken om bijvoorbeeld een rood vierkant op het scherm te tekenen.
Er doemt in mijn situatie echter wel een probleem op:

In een bepaalde kleur mogen sommige lichamen niet gemaakt worden:
- Een rood lichaam kan niet rond zijn
- etc...

In deze vorm dus

Ik hoop ook dat duidelijk is dat de keuzeboom die ik hier laat zijn een metafoor is voor wat ik wil.

Bij de eerste voorbeeld had ik het idee de keuzeboom in de while loop langs te gaan (=minder source)

Bij het tweede voorbeeld had ik het idee alles in verschillende functies te zetten (=overzichtelijker)

Ik hoop dat het nu wat duidelijker is

[Alarmnummer]

Even een snelle reply.. Je moet gaan voor overzichtelijkheid als dit geen tig keer per seconden aangeroepen hoeft te worden. Ik zal zo even een langere reply schrijven (als ik precies erachter kom wat jij bedoelt )

Vraag. Ik vind het een beetje eigenaardig dat een frame een multidimensionale array is. En frame zou toch zoiets moeten zijn?

code:

public class Frame{
   public static final int ROOD = 1;
   public static final int BLAUW = 2;

   public static final int VIERKANT = 1;
   public static final int DRIEHOEK = 2;
  
   private int _kleur;
   private int _vorm;
 
   public Frame(int kleur, int vorm){
    .... 
   }

   getters
}

Je hoeft maar zoveel integers zijn als er informatie is. In dit geval hoef je dus maar 2 integers over te sturen.

ps: geen commentaar over deze code aub (met name martin ), want constanten op deze manier zijn een big nono

[mvt]

Teken eerst een goede beslisboom (zo opgesteld dat hij het minste aantal bslissingen hoeft te maken, scheelt in rekenkracht). Scan hem in en plaats hem hier.

[Verwijderd]

code:

    [.......Lichaam................]
     /       |        \
 [...rood....] [....geel....] [....blauw....]
 /      \   /     \    /     \
[vierkant] [rond] [driehoek] [rond] [vijfkant]

Sorry, maar er is geen scanner aanwezig, toch hoop ik dat
de boom duidelijk is

[Alarmnummer]

Ik zou die boom niet in de code plaatsen, maar zelf een boom schrijven. En dan kan je bij iedere node weer beslissen welke leaf hij in moet gaan.

[Alarmnummer]

Maar wat probeer je eigelijk te doen? Je probeert te achterhalen wat de gegevens zijn van het object dat je hebt opgehaald via het netwerk?

[mvt]

Op maandag 22 juli 2002 10:41 schreef KlukKluk het volgende:

code:

    [.......Lichaam................]
     /       |        \
 [...rood....] [....geel....] [....blauw....]
 /      \   /     \    /     \
[vierkant] [rond] [driehoek] [rond] [vijfkant]

Sorry, maar er is geen scanner aanwezig, toch hoop ik dat
de boom duidelijk is

Is de beslissing op basis het blad waarin je uitkomt goed.
Is de actie die volgt op een rood rond lichaam hetzelfde als die van een geel rond lichaam??
Is het zo dat bijvoorbeeld blauw altijd dezelfde actie heeft, dit scheelt een beslissing.
Is het zo dat je vaker rood dan geel verwacht, zoja, zet dit dan voor in de code, anders moet je geel voorin in de code zetten.

[mvt]

Op maandag 22 juli 2002 10:52 schreef Alarmnummer het volgende:
Maar wat probeer je eigelijk te doen? Je probeert te achterhalen wat de gegevens zijn van het object dat je hebt opgehaald via het netwerk?

En op basis van die eigenschappen die je een actie, of niet

[Verwijderd]

Ik probeer de eigenschappen over het netwerk op te halen en voor elk eindpunt dient een andere actie ondernomen te worden.

[Alarmnummer]

Hmmzz.. *ziet hier veel leuke oplossingen oa een visitor design pattern*

wat voor oplossing wil je? een simpele of een mooie?

[Verwijderd]

Ik moet het ook aan anderen laten zien.

De mooie dus

[Alarmnummer]

Ok hier komt een beetje een overgedesignde oplossing

Wat jij wilt is dus informatie overzenden over het netwerk. Je zou daarvoor dit kunnen doen:

code:

class Frame{
    public final static int ROOD = 0;
    public final static int BLAUW = 1;

    private int _kleur;

    public Frame(int kleur, int vorm, ...){
        
    }
}

Nu hoef je alleen nog maar zoveel integers over te sturen als er velden zijn. Maar ik vind integers alijd een beetje vervelend omdat ze niet helemaal duidelijk zijn in hun betekennis. Als het niet honderden keren per seconde over het netwerk gestuurd hoefd te worden dan zou ik zelfs gaan voor het versturen van strings. In het onderstaande gedeelte zie je hoe ik dit heb gedaan.

code:

abstract public class Kleur{

    public static final ROOD = new Roow();
    public static final BLAUW = new Blauw();

    private static Map s_kleurMap = new HashMap();

    public static get(String kleur){
        return (Kleur)s_kleurMap.get(kleur);
    }

    private String _naam;   

    Kleur(String naam){
        _naam = naam;
        s_kleur.put(naam,this);
    }

    abstract public void accepts(KleurVisitor visitor);     

    public String getNaam(){
        return _naam;
    }
}

final public class Rood{
    
    Rood(){
        super("Rood");
    }

    public void accepts(KleurVisitor visitor){
        visitor.visit(this);
    }
}

final public class Blauw{

    Blauw(){
        super("Blauw");
    }

    public void accepts(KleurVisitor visitor){
        visitor.visit(this);
    }
}

public interface KleurVisitor{
    
    public visit(Rood rood);

    public visit(Blauw blauw);
}

public abstract class KleurAdapter implements KLeurVIsitor{
    public visit(Rood rood){
        visitDefault(root);
    }

    public visit(Blauw blauw){
        visitDefault(blauw);
    }

    public visitDefault(Kleur kleur){
    }
}

public class JouwData{
    private Kleur _kleur;

    public JouwData(Kleur kleur){
        _kleur = kleur;
    }

    public Kleur getKLeur(){
        return _kleur;
    }
}

Op het moment dat je een string binnen krijgt, dan kan je heel eenvoudig het object weer terug krijgen wat daar bij hoort.

Kleur kleur = Kleur.get(kleurText);
Vorm vorm = Vorm.get(vormText);

En nu kan je jouw object weer opbouwen:

JouwData jouwData = new JouwData(kleur,vorm,...);

Als je nu wilt dat er een actie op jouw data wordt ondernomen, bijvoorbeeld de kleur rood afkeuren dan kan je het volgende doen:

code:

public class HeeftHekelAanRoodAfdrukker extends KLeurAdapter{
    public visit(Rood rood){
        System.out.println("Jaaaahh.. het is rood!!!");
    }
}

jouwData.getKleur().accepts(new HeeftHekelAanRoodAfdrukker());

Wat je hierboven zit is het visitor design pattern (vandaar die accepts methoden in Kleur, Rood en Blauw). Hierdoor kan je een bepaalde functionaliteit toevoegen aan een bepaald object, zoals ik hier een bepaalde functionaliteit heb toegevoegd aan Rood.

[Alarmnummer]

Ik zie dat je verder ook behoefte hebt aan bepaalde constraints. Ik zal even kijken hoe ik dat op kan lossen.

[Alarmnummer]

Nu zijn de constraints ook ingebouwd, met een externe controle class. Dit komt de overzichtelijkheid ook tengoede.

code:

public class JouwData{
    private Kleur _kleur;
    private Vorm _vorm;

    public JouwData(Kleur kleur, Vorm vorm){        
        Validator validator = new Validator(kleur,vorm);
        _kleur = kleur;
        _vorm = vorm;
    }

    public Kleur getKLeur(){
        return _kleur;
    }

    public Vorm getVorm(){
        return _vorm;
    }
}

private class Validator{
        
    private Vorm _vorm;

    public Validator(Kleur kleur,Vorm vorm){
        _vorm = vorm;
        _kleur.accepts(new KleurVisitorImpl());
    }

    private class KleurVisitorImpl extends KleurAdapter{
        public void visit(Rood rood){
            VormVisitor vormVisitor = new VormVisitorAdapter{   
                public void visit(Rond rond){
                    throw new IllegalArgumentException("rood en rond wil niet samen");
                }

                public void visit(Vierkant vierkant){
                    throw new IllegalArgumentException("rood en vierkant willen niet samen");
                }
            }
    
            _vorm.visit(vormVisitor);
        }

        public void visit(Blauw blauw){
            VormVisitor vormVisitor = new VormVisititorAdapter(){
                public void visit(Driehoek driehoek){
                    throw new IllegalArgumentException("blauw en driehoek willen niet samen");
                }
            }
                        
            _vorm.visit(vormVisitor);
        }

        public void visit(Groen groen){
            VormVisitor vormVisitor = new VormVisititorAdapter(){
                public void visit(Driehoek driehoek){
                }
            
                public void visitDefault(Vorm vorm){
                    throw new IllegalArgumentException("alleen groene driehoeken zijn goed");
                }
            }
            _vorm.visit(vormVisitor);
        }
    }
}

[edit]
prog foutje

[lordsnow]

Uiteindelijk zijn er dus maar 6 juiste kleur-lichaam mogenlijkheden?! Kan je dan niet 6 keer CASE gebruiken?

[Alarmnummer]

Op maandag 22 juli 2002 12:01 schreef lordsnow het volgende:
Uiteindelijk zijn er dus maar 6 juiste kleur-lichaam mogenlijkheden?! Kan je dan niet 6 keer CASE gebruiken?

Het kan goed uit de hand lopen als je veel combinaties hebt, en mijn oplossing is de oo versie van een case statement

[Juicy]

En wat is het idee hier achter ?
Het is toch zeker geen huiswerk, he ?!

[Alarmnummer]

Op maandag 22 juli 2002 12:06 schreef Juicy het volgende:
En wat is het idee hier achter ?
Het is toch zeker geen huiswerk, he ?!

Zo lang mensen hun huiswerk zo neerzetten, heb ik er geen problemen mee. Hij legt het probleem goed uit, en hij geeft zelf ook al een aantal oplossingen. Dit valt dus zeker niet onder de categorie: 'ik snap het niet, en willen jullie het even maken'.

[Verwijderd]

Vanwege het feit dat ik geen OO wonder ben zal ik eerst de source van Alarmnummer flink moeten bestuderen, het lijkt me echter wel een nettere oplossing dan ik eerst in gedachten had

[Alarmnummer]

Dan heb je [url="http://www.sablecc.org/thesis/thesis.html"]hier[/url] misschien nog wel iets aan. Je moet dan even doorscrollen naar 6.1 Hier zie je heel duidelijk het verband tussen de visitor en een switch case commando. En als je dan nog een keer goed kijkt, dan zie je dit ook in mijn code terug. Alleen heet Switch nu Visitor, caseXXX heeft nu visit en apply heeft accepts.

En zie verder mijn signature wat ik van visitors vind Visitor bieden je de mogelijkheid om functionaliteit te scheiden van je data. Zoals je zit zit in jouwData geen speciale functie om te gillen als er rood in zit, maar toch kon dit heel eenvoudig worden toegevoegd. Op dit moment maak ik mijn meeste model objecten zodat ze alleen data dragen en alle validatie methodes hebben en verder bijna niets meer. Alle functionaliteit voeg ik toe mbv visitors, en het begint helemaal interessant te worden als je ook nog traversals gaat doen op structuren mbv visitor guide`s

Visitors zijn

[Verwijderd]

Dus je hebt een boom, nou het eerste wat in mij opkomt is recursie. Dat is de meest gangbare manier om een boom door te fietsen. Maar ja, dat zou alleen handig zijn als je ook daadwerkelijk iets aan de boom had. En dat heb je volgens mij niet.

Nou iemand heeft het al in Java uitgetikt ( beetje jammer, het is beter om het goed te beschrijven inplaats het gelijk in code om te zetten ). Het is een van de vele opties.

Dus ja, als we het dan in woorden omzetten:
1-Haal informatie over het netwerk binnen
2-zet een veriabele naar het eerste element van het pakket
3-Kijk naar het element en kies vervolg actie
4-verhoog de variabele en naar stap 2.

[Alarmnummer]

Op maandag 22 juli 2002 13:35 schreef markvleth het volgende:
Dus je hebt een boom, nou het eerste wat in mij opkomt is recursie.

Het is niet een zichzelf herhalende datastructuur zoals een boomstructuur van mbv mensen (ouders, kinderen etc etc). Daarom gaat recursie hier ook niet op.

En als er wel sprake was van recursie dan had je dit perfect op kunnen lossen met visitor guide`s. Hierdoor kan je traversal scheiden van de operatie en hierdoor kan je dus een bepaalde traversal herbruiken.

vb.

expressie.accepts(new InFixGuide(new Printer());
expressie.accepts(new PostFixGuide(new Printer());

je ziet dat je hier de traversal Infix en PostFix kan hergebruiken voor allerlei doeleinden

Nou iemand heeft het al in Java uitgetikt ( beetje jammer, het is beter om het goed te beschrijven inplaats het gelijk in code om te zetten ).

Persoonlijk vind ik een stukje code meestal wel zo verhelderend en ik heb hem al een link gegeven naar de uitleg hiervan

En verder biedt jouw oplossing geen uitkomst, omdat hij nog steeds geen actie kan ondernemen op een waarde als hij een waarde heeft binnen gekregen.

[Verwijderd]

Het nadeel van het direct omzetten naar een progtaal is dat je er verder niks meer mee kunt. Herschrijven naar een andere taal duurt langer. Je kunt beter gewoon een universele blauwdruk hebben.

[Alarmnummer]

Op maandag 22 juli 2002 13:47 schreef markvleth het volgende:
Het nadeel van het direct omzetten naar een progtaal is dat je er verder niks meer mee kunt. Herschrijven naar een andere taal duurt langer. Je kunt beter gewoon een universele blauwdruk hebben.

Ik vond UML wat te ver gaan, en ik vind java behoorlijk geschikt als pseudo taal door zijn eenvoud en duidelijkheid. Ik denk ook niet dat het omzetten naar C++,C#, Nice en Delphi (weet even niet zo snel andere oo varianten meer en ik zal hem maar geen Simula aan doen ) al te veel problemen gaat opleveren aangezien de meeste talen wel dezelfde oo concepten hebben. Daarnaast is de topic starter geloof ik bezig in Java aangezien hij daar de laatste tijd vaker topics over is begonnen.

Trouwens met Nice was die hele visitor niet nodig geweest

[Verwijderd]

En verder biedt jouw oplossing geen uitkomst, omdat hij nog steeds geen actie kan ondernemen op een waarde als hij een waarde heeft binnen gekregen.

Dat is ook helemaal niet interessant. Dat is veel te taal afhankelijk, vandaar dat je dat soort acties bijna nooit opneemt. Plus dat de topicstarter juist vraagt naar een algoritme om het doorlopen van de data zo makkelijk mogelijk te doen. Zijn voorstel is met en aantal case-switch statements.

[Verwijderd]

Trouwens met Nice was die hele visitor niet nodig geweest

Conclusie, je bent niet taal onafhankelijk bezig...

[Alarmnummer]

Op maandag 22 juli 2002 13:57 schreef markvleth het volgende:
Dat is ook helemaal niet interessant.

Dat is juist wel interessant. De topic starter die wil een bepaald object over het netwerk versturen. Hij wil bij aankomst van die waarden een bepaalde actie ondernemen (in zijn geval wil hij op dit moment printen) maar hij zal uiteindelijk dat object ook weer volledig willen opbouwen aangezien hij het op het scherm wil tekenen. Ik heb hem een basis source aangeleverd waarin hij dit allemaal kan doen op een zeer fraaie manier. ALs je denk ik even goed door de code gaat kijken dan zul je dit ook moeten concluderen.

Dat is veel te taal afhankelijk, vandaar dat je dat soort acties bijna nooit opneemt. Plus dat de topicstarter juist vraagt naar een algoritme om het doorlopen van de data zo makkelijk mogelijk te doen. Zijn voorstel is met en aantal case-switch statements.

1) jij geeft hem totaal geen oplossing, alleen een loopje hoe hij door zijn data kan lopen. Ik denk dat de topic starter genoeg kennis heeft om dit ook voor elkaar te krijgen.
2) ik bied hem dus met die Kleur class een mogelijkheid om zijn 'objecten' weer terug te krijgen en zijn model op te bouwen, ik bied hem de mogelijkheid voor validatie (zie de Validator) en ik bied hem de mogelijkheid om zometeen op een zeer fraaie manier zijn componenten te kunnen teken.

Conclusie, je bent niet taal onafhankelijk bezig...

Ik heb hem een taal onafhankelijk concept in de hand gedaan, namelijk multidispatch. In de meeste oo talen is dit niet mogelijk, en daarom moet er een omweg voor gevonden worden. Deze omweg is het visitor design pattern, en deze is ook nog vrij taal onafhankelijk Ik ben het dus niet met je eens. En verder vind ik je conclusie ook een beetje 'kleingeestig'. Mijn vraag is dan ook of jij weet wat het visitor design pattern inhoud?

[Verwijderd]

We zitten duidelijk niet op 1 lijn Alarmnummer. Ik ga er ook niet verder op in omdat je jezelf continu tegenspreekt (bijvoorbeeld beperkingen van talen, en zeggen dat je alles zo om kunt zetten naar een andere taal). Over de code zelf heb ik verder ook geen opmerkingen, die ziet er degelijk uit.

[Alarmnummer]

Op maandag 22 juli 2002 14:32 schreef markvleth het volgende:
We zitten duidelijk niet op 1 lijn Alarmnummer.

Ik geloof het ook niet

Ik ga er ook niet verder op in omdat je jezelf continu tegenspreekt (bijvoorbeeld beperkingen van talen, en zeggen dat je alles zo om kunt zetten naar een andere taal).

In de meest voorkomende oo talen zoals Delphi, C++, Java en C# zitten meestal dezelfde oo constructies en daarom kan mijn voorbeeld ook zo omgezet worden naar die talen. Er zijn alleen een paar exotische talen zoals CLOS en Cecil die wel multi dispatching zijn (maar wie progt hier nou in).

Daarom is de visitor een breed geaccepteerde design pattern om multidispatch te simuleren in talen waarin dit niet aanwezig is. In dat opzicht is de visitor design pattern een goeie algemene oplossing voor 99% van de gebruikte oo talen, en derhalve kan dit voorbeeld ook naar die talen worden getransformeerd.

IK ben het wederom niet met je eens. Ik vind trouwens je antwoorden nog steeds erg slecht onderbouwd en naar mijn inziens getuigen van een gebrek aan oo kennis.

Over de code zelf heb ik verder ook geen opmerkingen, die ziet er degelijk uit.

Dat weet ik

[jvdmeer]

Op maandag 22 juli 2002 10:41 schreef KlukKluk het volgende:

code:

    [.......Lichaam................]
     /       |        \
 [...rood....] [....geel....] [....blauw....]
 /      \   /     \    /     \
[vierkant] [rond] [driehoek] [rond] [vijfkant]

Sorry, maar er is geen scanner aanwezig, toch hoop ik dat
de boom duidelijk is

ik heb de tussenliggende discussie over oo niet helemaal gevolgd, maar is de boom in een andere volgorde niet handiger?

code:

 [.......Lichaam................]
 /      |     |   \
[vierkant] [rond] [driehoek] [vijfkant]
        /   |  \
    [rood][geel][blauw]

Want de keuze is al direct bepaald zodra er een drie,- vier of vijfhoek binnenkomt, nl. resp. geel, rood en blauw. Scheelt weer wachten op kleur

[Verwijderd]

Op maandag 22 juli 2002 11:35 schreef Alarmnummer het volgende:

code:

{
public abstract class KleurAdapter implements KLeurVIsitor{
    public visit(Rood rood){
        visitDefault(root);
    }

    public visit(Blauw blauw){
        visitDefault(blauw);
    }

    public visitDefault(Kleur kleur){
    }
}

Dit stuk begrijp ik niet, wat is het nut van visitDefault en bovendien roept heeft hij een ander object als argument (Kleur tov. Blauw/Rood). Er is hier bovendien sprake van een abstracte class, de functies worden toch van de derived class gebruikt. Of zie ik hier iets simpels over het hoofd.

Kun je dit fragment toelichten?

[Alarmnummer]

Als je een interface maakt, dan is het vaak handig om ook een adapter te maken als die interface meerdere methodes heeft. Neem bijvoorbeeld de mouseListener. Als je alleen bent geinteresseerd in een mouseClicked dan heb je geen zin om al die andere methodes ook te implementeren (dat is verplicht bij de implementatie van een interface). Daarvoor heb je dus de adapter class. De class zal dus uiteindelijk ergens geextend moeten worden, want verder heeft hij geen betekennis, vandaar ook nog een abstract.

Als je nog even goed kijkt naar de overerfingshierarchie dan zie je dat Rood en Blauw allebei erven van Kleur, dus als je in visit(Blauw blauw) zit dan mag je gerust visitDefault(blauw) aanroepen.

Maar wat is het nut van die default methode?

Als we nog een keer die mouseListener bekijken, en ik wil graag weten of er iets met die muis gebeurd (maakt me niet uit wat) dan zou ik iedere methode van de interface kunnen overriden om dan bv een System.out te doen. Maar doordat iedere methode (in die Adapter) die default aanroept als jij hem niet zelf override, hoef je dus alleen nog maar die default te overriden om alle mouseEvents te pakken.

Kijk nog maar eens goed naar die Validator en visit(Groen groen). Daaronder werk ik dus ook met een visitDefault.

Ik hoop dat je hier een beetje mee uit de voeten kan

oeps.. ik zie rood staan met een t

[Macros]

Wat een gedoe zeg. Als je dat ook allemaal zo erin gaat coden ben je weer uren bezig als je weer wat moet veranderen van wat wel en niet mag.
Kan je niet beter een zooi arrays maken met de dingen die wel mogen. Dan kan je met een snelle isInArray() bepalen ofdat het mag ja of nee. Mag het niet kan je dynamisch de foutmelding genereren.
Lijkt me veel makkelijker dan die oplossingen die gegeven worden.
* Macros houdt nogal van geneste arrays in van die gekke talen zoals PHP, dat maakt het helemaal simpel
Maar stel een Ronde vorm mag alleen rood of blauw zijn en nog wat andere zooi erin.
Dan maak je een array 2 dimensionale array met eerst alle vormen en daarin alle kleuren. In php zou dat kunnen
$allowed = array();
$allowed[rond] = array("rood","blauw");
$allowed[vierkant] = array("groen");
Zo doe je dat met elke stap in je boom. Je kan dan in allowed zelfs kleuren en andere dingen zetten.
$allowed[rood] = array("vierkant");
Dan kan je het zelfs andersom bepalen. En dan een klein stukje code om te kijken ofdat het mag. Maar dat kan je in php zelf wel uitzoeken. In andere talen zal het ietsje lastiger gaan, maar met opzoek tabelen zal het vast wel gaan. Ik denk dat het slimmer is om de data waarmee je werkt uit de code te houden. Dus geen functie namen vernoemd naar materiaal soorten/vormen/kleuren en andere data eigenschappen. Zodra je dat hebt zal blijken dat de code teveel data afhankelijk is wat later aanpassen van de code lastig maakt.

[Alarmnummer]

Het ligt er een beetje aan wat voor soort objecten je gaat krijgen. Zoals ik hierboven vermeld had is deze oplossing een beetje overdesigned (zal beter mijn anti patterns moeten bestuderen ). En zo gauw je veel kleuren en vormen gaat krijgen is niet handig om het op deze manier op te lossen. Het legt maar net waar je de grens trekt tussen generieke data, of een eigen object met eigen specifieke eigenschappen en acties.

Ik gebruik zelf het visitor design pattern veel voor structuren die ik van te voren kan bepalen en daar zie je dan de kracht ook met het visitor design pattern.

Je ziet hier dat die validator ook vrij groot begint te worden als je 2 eigenschappen hebt waarop je wilt controleren. Het is bij grotere aantallen wel handiger om een boom te maken waarin alle goeie combinaties staan. Deze boom die kan compile time beschreven worden, maar zit verder niet in code versleuteld. Hierdoor kan je ook veel makkelijker op bepaalde eigenschappen controleren.

Ik zou verder eigelij zo weinig mogelijk arrays gebruiken omdat dat toch wel een beetje achterhaalde structuren zijn en toch gaan voor een hashmap of een search tree waar je snel iets kan vinden. Hiermee geef je ook veel duidelijker aan wat je bedoelt met een bepaalde structuur. Daarom ben ik in veel opzichten ook niet zo blij met php`ers omdat hun code eigelijk vrij onduidelijk is.

[Macros]

Een array in PHP is eigenlijk helemaal geen normale array zoals in alle andere talen. Het is eigenlijk alle soorten container structeres in 1 (wat makkelijk kan voor een niet gecompileerde taal).
Ik wilde alleen een voorbeeld geven hoe het beter kan dan via functies/methodes of switch/case structuren.