Go Down

Topic: Anleitung Ein Endlicher Automat entsteht (Read 13387 times) previous topic - next topic

guntherb

Vielen Dank!

Aber ein komplett unkommentierter Code ist dann schon echt hart.

ich hatte mit etwas erhofft, wie agmues "millisverzögerung", nur eben als class, so dass vielfache Aufrufe nicht zur Kollision führen.

Ich werde heute abend mal versuchen, zu verstehen was da passiert.

Wenn nicht, mach ichs halt weiter manuell mit if (millis()- ts > 500 )...


Grüße
Gunther

combie

Quote
Ich werde heute abend mal versuchen, zu verstehen was da passiert.
Ich denke, da besteht Hoffnung.

Und zu den Kommentaren, da weiß ich gar nicht, was ich da hinschreiben sollte, außer meiner Adresse, Namen und Email...

Im Grunde ist die Funktion recht schlicht.

Die Klasse Handler bildet eine einfach verkettete Liste.
Jedes neu erzeugte Objekt (ein Kind von Handler) reiht sich bei der Erzeugung in die Liste ein.
Die Liste ist Singleton, oder besser, statisch.

Es werden 3 LED Objekte erzeugt.

In der Loop reicht ein Aufruf der handle Methode, damit die Liste durchlaufen wird. Von jeder LED wird die update() Methode aufgerufen.

Und das was du eigentlich sehen wolltest, steckt in der update().
Jede LED führt ihren eigenen unabhängigen 20ms Timer mit sich.

Auf irgendwelche Destructoren habe ich keine Rücksicht genommen, da dynamische Speicherverwaltung auf Arduinos sowieso böse ist.


Es sind also 3 aller einfachste endliche Automaten, welche quasi unabhängig von einander arbeiten.
Nach entfernen des Serial Gedöns, ist die setup leer.
Und in der loop nur ein Aufruf.

Es ist ein Beispiel für Kapselung. (vielleicht nicht das beste/schönste, aber konsequent)
Das hinzufügen von gleichartigen LEDs ist ein Kinderspiel.

Lagert man die Klassen in eine Lib aus, dann ist das Beispiel plötzlich superschlank.


Heute war Gestern Morgen.
Heute ist Morgen Gestern.
Morgen ist Heute Gestern.
Gestern war Heute Morgen

michael_x

Quote
Und zu den Kommentaren, da weiß ich gar nicht, was ich da hinschreiben sollte
z.B. :
Wofür die Klasse Handler überhaupt, und insbesondere der singleton Handler::first gut ist
warum der Konstruktor Handler() protected ist und nicht public,
warum neue Handler vorne eingehängt werden und nicht hinten.

und so Sachen eben ... ;)

Serenifly

warum der Konstruktor Handler() protected ist und nicht public,
Damit man kein Handler Objekt erstellen kann?

Quote
warum neue Handler vorne eingehängt werden und nicht hinten.
Das hat mich auch erst mal verwirrt :)

combie

#19
Jul 20, 2015, 05:35 pm Last Edit: Jul 20, 2015, 05:43 pm by combie
Quote
warum der Konstruktor Handler() protected ist und nicht public,
Das ist ja mal eine gute Frage...

Ist "automatisch" so passiert, ohne nachzudenken. (so weit ist es schon 8) )
Ich schränke grundsätzlich die Sichtbarkeit von Eigenschaften und Methoden möglichst weit ein.
Hier führt es dazu, dass von Handler keine Instanz erzeugt werden kann.
update() ist übrigens auch protected. Kein Aufruf von außen sinnvoll, oder gar nötig.

Quote
warum neue Handler vorne eingehängt werden und nicht hinten.
Ob vorn oder hinten....
So ist es etwas schlanker/einfacher.
(zumindest aus meiner Sicht)
Heute war Gestern Morgen.
Heute ist Morgen Gestern.
Morgen ist Heute Gestern.
Gestern war Heute Morgen

michael_x

#20
Jul 20, 2015, 06:18 pm Last Edit: Jul 20, 2015, 06:36 pm by michael_x Reason: combie hat Recht
Nur so als Tip für guntherb:

Das ist keine einfache Einführung in oop im Allgemeinen.

Eine Hilfsklasse, von der man kein Element erzeugen kann, die aber für alle abgeleiteten Elemente eine gemeinsame statische Methode (handle()) bereitstellt. Die also nur dafür da ist, dass man in loop nicht sieht, wie viele Elemente aufgerufen werden, was aber im Beispiel gar nicht gebraucht wird, weil da nur eines existiert.

Name, adresse, email wäre ein schlechter Kommentar, combie 8)

combie

Quote
Die also nur dafür da ist, dass man in loop nicht sieht, wie viele Elemente aufgerufen werden, was aber im Beispiel gar nicht gebraucht wird, weil da nur eines existiert.
eines
drei
 :smiley-mr-green:
Heute war Gestern Morgen.
Heute ist Morgen Gestern.
Morgen ist Heute Gestern.
Gestern war Heute Morgen

michael_x

sorry, Du hast Recht.
Hab mir erlaubt, meinen vorigen Kommentar zu korrigieren.

Das das Ganze sinnlos ist, hab ich auch nicht behauptet ;)

Ob es sich kommentarlos als Einführung in oop eignet, kann guntherb beurteilen, wenn er damit durch ist.

combie

#23
Jul 20, 2015, 06:56 pm Last Edit: Sep 13, 2016, 06:18 pm by combie
Das das Ganze sinnlos ist, hab ich auch nicht behauptet ;)
Ich glaube, das darf man alles nicht so ernst nehmen ....

Nimm den Code als Witz, hmm..., nicht Witz, aber Code mit Humor...


Damals....
Als ich mal eine Visualisierung für eine FCKW Absaugmaschine gebastelt hatte, zeigte ich dem TÜV Menschen die Hauptdatei.
Ein Turbo6 Projekt von mir:
(der ist vor lachen fast umgefallen)
Code: (pascal) [Select]
Program Visual;

Uses
   Protokoll,Scheduler,Visualisierung  // und so weiter

Const
   StromAusfall = FALSE;

Begin
   while(not StromAusfall) do  Schedule();
End;
*aus dem gedächtnis also ohne Gewähr*
Das diente dazu Kooperatives Multitasking unter  MS-DOS zu implementieren..

Heute war Gestern Morgen.
Heute ist Morgen Gestern.
Morgen ist Heute Gestern.
Gestern war Heute Morgen

Go Up