denn die Tatsachen widersprechen meinem Gefühl,
Guter Ansatz!
Damit spielen ist genau der richtige Weg.
Wie die Kinder.
Immer wenn man sich nicht gerade in einer akuten Notlage befindet, lohnt es sich, solchen Widersprüchen/Auffälligkeiten nach zu gehen.
Ich nenne diesen Zünder "Sprung in der Projektion"
z.B. Hier, hier,hier und hier
Naja.. wird bestimmt noch häufiger von mir kommen.
Spannendes Thema eigentlich.... auch für das Restleben, außerhalb der µC.
Hat aber auch nur am Rande mit OOP zu tun.
Wie die vielen kleinen anderen Werkzeuge auch.
Mein Antrieb heißt Faulheit. Ich kann viel Energie aufwenden, um es mir gemütlich zu machen. Deine for-Schleife, die nichts mit OOP zu tun hat, war so schön einfach. Meine Faulheit zeigte sich interessiert. Darüber stellte ich fest, in einer Funktion mit einer Indexvariablen jonglieren zu müssen, während eine Methode ohne Index auskommt. Eine Mühe und Fehlerquelle weniger, das motiviert.
Je länger ich darüber nachdenke...
Desto mehr glaube ich, dass du recht hast.
Ja, ich denke, dass Faulheit durchaus eine meiner Motivationen ist, so manches mal tief in die Werkzeugkiste zu greifen. Vielleicht sogar die treibenste.
Angst ist kein guter Ratgeber (außer in echter Not).
Faulheit scheinbar schon...
Mantra:
Wenn du etwas drei mal auf die gleiche Art getan hast,
dann mache eine Funktion/Klasse draus.
Der Vorteil der Geschichte ist ganz klar. Einmal schreiben, ordentlich debuggen und kommentieren, danach immer nur stumpf einsetzen.
Dinge auf Wiederverwendbarkeit auszulegen ist etwas Arbeit.
Austesten, probieren, und üben. Damit spielen.
Aber danach, kann man die Innereien dieser Komponente vergessen.
Nur noch einsetzen.
Das Beispiel mit dem Holzklotz ist Klasse, das verstehe ich sofort!
Schön, dass es dir gefällt!
Im Grunde ist es diese Naivität, welche es zu gewinnen gilt. Prozedurale Programmierer konzentrieren sich gerne auf die Komplexität eines Problems. Das führt dazu, dass man beim betrachten eines OO Programms den Wald vor Bäumen nicht mehr sieht. Man sieht die komplexen(vielleicht sogar noch unbekannten) OOP Sprachmittel, aber die Naivität der Objekte, ihre klaren Schnittstellen, sind eher weniger auffällig.
Der prozedurale Programmierer hat gerne den Programmfluss vor sich.
Diesen sieht er aber im OOP Programm nicht. Da sieht das alles irgendwie verworren aus.
Denn dort stehen die Dinge in Beziehung zueinander.
Und aus den Beziehungen, der Dinge untereinander, entsteht der Programmfluss automatisch.
Wenn man einzig auf den Programmfluss aus ist, wird man sich nur unter großen Verrenkungen ein Bild davon machen können.
Die Naivität macht schon einen großen Teil der OOP Denke aus.
if(digitalRead(tasterPin) == LOW)
{
tueMitLed(HIGH);
} else
{
tueMitLed(LOW);
}
Oft gesehenes Beispiel.... in vielen Variationen ....
Das kommt der prozeduralen Sicht sehr entgegen.
Ist also aus prozeduraler Sicht als naiv anzusehen.
Steigerungen sind leicht möglich:
tueMitLed(!digitalRead(tasterPin));
Hier werden schon Taster und LED in Beziehung gesetzt.
In, oder mit der Lib, geht es auch so:
led = taster;
Der naive prozedurale Programmierer bekommt einen Schock.
"Wie jetzt? Warum soll die Led plötzlich ein Taster sein?"
Ich, als naiver OOPler, denke, ich brauche einen Taster.
Ich brauche dauernd Taster.
Also mache ich mir, ein für alle male, einen Taster.
Was muss dieser Taster können?
Was muss ich damit anstellen können?
Im Grunde sind das nur zwei Sachen.
Ich muss ihn einmal initialisieren, ab dann ist er bereit, seinen Job zu tun.
Und sein Job?
Immer, wenn ich ihn frage, ihn in Software anfasse, hat er mir seinen Zustand zu liefern.
Fertig!
Damit kann man 99.9% aller Tasterabfragen/Anwendungen abhandeln.
Mit der Led ist es ähnlich.
Initialisieren, damit sie bereit ist das zu tun, was man von ihr will.
Zustand ändern, wenn die Nachricht kommt.
led = taster;
Der Taster liefert seinen Zustand, was anderes kann er nicht, und dieser Zustand wird der LED zugewiesen. Diese empfängt die Nachricht und tut, was zu tun ist.
Einen Tick weiter in OOP gedacht, würde man das "Subjekt Observer Design Pattern" implementieren.
Der Taster würde zum Subjekt, die LED zum Observer.
In setup(), oder gar noch vorher, in einem Konstuktor, würde man dann die Beziehung der beiden etablieren, und im Rest des Programms nichts mehr davon sehen.
OK, in meiner Lib ging mir das zu weit.
Das stand ganz klar im Widerspruch zu "nur das nötigste".
Aber dennoch steht es jedem frei, von den Klassen zu erben, und das dann auf dem Wege nachzurüsten.
Das ist dann aber nicht mehr nur OOP, sondern auch schon Teil der "Ereignis orientierten Programmierung"
Ach...
Das mischt sich doch sowieso alles....
:o :o :o :o :o
