🚀 go-pugleaf

Wat ik geleerd heb is dat gui en logica altijd gescheiden moeten blijven,
daarmee wil ik zeggen, de gui is de front end, klassen en objecten zijn
backend, daar is een naam voor die me nu niet direct te binnen schiet maar
dat doet er ook niet veel toe. Waar het in dit geval op neer komt is dat de
klasse, of het object ervan, eigenlijk een logische kopie is van je gui
speelveld. Op de form staat een array van labels, deze wordt bijgehouden in
de klasse, maar dan vertaald in een array van ints of bools. Je hebt dus
eigenlijk twee verschillende arrays en delen in je programma: eentje voor de
gui en eentje voor de klassen/objecten. De gui baseert zich op de
onderliggende klassen om "na te denken" en om dingen uit te voeren.
Dus: twee arrays: eentje van labels op je form die je dynamisch cre�ert en
eentje in je klasse waarop de gui zich moet baseren om afhankelijk van de
waarden in deze array een muur of een doorgang te maken (met verschillende
kleurtjes dus). Stel dat je in je array in het object van de klasse
speelveld een 0 neemt voor een doorgang, en een 1 voor een obstakel, dan
moet je als je de labels op je form aan het plaatsen bent bvb groen nemen
als het vakje in het object 0 is, en zwart indien daar 1 in staat.

In het begin had ik daar ook problemen mee hoor om de twee gescheiden te
houden en t'klonk alles behalve logisch maar  ��nmaal je mee bent zal je dat
altijd zo doen en meteen zelf inzien hoe je de logica erachter moet steken
bij allerhande toepassingen. Je beslissingen in een algoritme mogen nooit
rechtstreeks afhangen van event handlers of waarden in je gui (op je form
dus) die veranderen, deze events moeten een verandering triggeren in je
klassen/objecten van waaruit dan de nodige stappen moeten worden ondernomen.

Als je er echt niet uitkomt wil ik gerust een  simpel voorbeeldje maken
hoor, geen enkel probleem, maar probeer toch eerst zelf wat, zo leer je het
immers het beste :-)