Go Down

Topic: OOP für Anfänger - Einstieg mit nachvollziehbarer Erklärung (Read 8174 times) previous topic - next topic

Klaus_ww

Für alle wie mich, die schon lange um das Thema rumeiern aber bisher nicht den Einstieg gefunden haben.

Neben einführenden Basics hier ein Link, bei dem es im Block "Einführung in die OOP" bei mir endlich mal richtig Klick gemacht hat.

Vielleicht hilft es ja dem einen oder anderen auch, also <KLICK>
Freizeit-Programmierer mit moderatem Ehrgeiz besseren Code zu schreiben.

combie

Schön wenn es dir hilft...
Aber empfehlen kann ich es nicht.


Viele kleine Fehler.
Viele.

Teilweise falsche Begrifflichkeiten(gruselige Semantik), das erschwert die Kommunikation.


Irreführungen!
Ein angebliches  C Tutorial, welches aber in der Realität  C++ abhandelt.

> void funk(double &zeigerAufD)
Eine Referenz, welche Zeiger genannt wird.

Und viele derer mehr


Meine erster Eindruck:
Ein Anfänger Tutorial, welches von einem Anfänger geschrieben wurde.
Der Schreiber wiederholt nur, was er bisher gelernt hat, inklusive der Fehlinformationen.


Der OOP Teil zeigt, dass er die Verfahren teilweise durchaus verstanden hat.
Aber nicht die Philosophie dahinter.

OK, es kann einem auf die Sprünge helfen.
Aber man sollte sich dabei sehr bewusst sein, dass von dem gelernten später sehr viel korrigiert werden muss. Aus meiner Sicht ist es leichter, sofort das richtige zu lernen, als sich zwischendurch falsch gelerntes wieder aus dem Kopf kloppen zu müssen, und dann das richtige zu lernen. Doppelte Arbeit, und das auch noch gegen das eigene Beharrungsvermögen.
Wer seine Meinung nie zurückzieht, liebt sich selbst mehr als die Wahrheit.

Quelle: Joseph Joubert

Klaus_ww

Mir hat's geholfen, Feinschliff kommt nach dem Groben.
Alles was ich bisher an Einführungen gelesen habe lies mehr Fragen als Antworten zurück
Freizeit-Programmierer mit moderatem Ehrgeiz besseren Code zu schreiben.

combie

Quote
Alles was ich bisher an Einführungen gelesen habe lies mehr Fragen als Antworten zurück
Ja, so ist das wohl.
Ich halte das auch für logisch, angemessen und natürlich.
Nichts anderes ist zu erwarten, wenn man als "Frischling" ein großes unbekanntes Gebiet erobert.
Schnelle/Einfache Antworten verdecken eher das wesentliche, als dass sie es ans Licht bringen.


Frage deine Fragen!


Oder sage mir, welche deine Fragen der Artikel beantwortet hat...
(das würde mich wirklich interessieren)

Zwar habe ich gerade keine Programmierumgebung zur Verfügung, aber Fragen zu OOP kann ich gerne beantworten.
Wer seine Meinung nie zurückzieht, liebt sich selbst mehr als die Wahrheit.

Quelle: Joseph Joubert

Klaus_ww

Nun, mein Ansatz war und ist: an einem nachvollziehbaren Praxisbeispiel die grundsätzliche Vorgehensweise bei der OOP zu beschreiben und wie in dem Tutorial auch zu erklären.

Ich habe keinen aktuellen Anwendungsfall, aber eben "moderaten Ehrgeiz besseren Code zu schreiben" (und Fremdcode auch zu verstehen).

Das Problem mit den Fragen ist halt wie immer: richtig fragen bedingt schon entsprechende Kenntnisse.

Aktuell hänge ich halt in der Frage "Wie geht das mal an einem einfachen Beispiel gezeigt mit dieser sagenhaften OOP?"





Freizeit-Programmierer mit moderatem Ehrgeiz besseren Code zu schreiben.

agmue

Aktuell hänge ich halt in der Frage "Wie geht das mal an einem einfachen Beispiel gezeigt mit dieser sagenhaften OOP?"
Obwohl ich von OOP auf Arduino nicht überzeugt bin, habe ich mal etwas in OOP probiert. Bibliotheken verwenden das ja immer und manche Beispielprogramme auch. Mich hat sowas wie for (LEDS &l : led) l.blink(); von combie gelockt, selbst zu probieren. In einem anderen Thema habe ich gerade prozedural nach OOP "verschoben". Ist kein Lehrbuch, auch kann ich für die Qualität nicht garantieren, aber der Compiler ist glücklich und Du kannst ja mal schauen.

Fragen kannst Du, für gute Antworten kann ich aber nicht garantieren :)
Die Vorstellungskraft ist wichtiger als Wissen, denn Wissen ist begrenzt. (Albert Einstein)

combie

Quote
Ich habe keinen aktuellen Anwendungsfall,
Das ist eigentlich schade.


Quote
aber eben "moderaten Ehrgeiz besseren Code zu schreiben" (und Fremdcode auch zu verstehen).
Das kann ich verstehen!
Deckt es sich doch auch mit meiner Motivation.


Quote
an einem nachvollziehbaren Praxisbeispiel die grundsätzliche Vorgehensweise bei der OOP
In der Annahme steckt meines Erachtens nach ein kleiner Fehler.

Denn eigentlich gibt es keine grundsätzliche Vorgehensweise.
Es gibt nur eine konkrete Vorgehensweise, bei einem konkreten Beispiel/Problem.

Auch konzentriert man sich nur selten auf eine Vorgehensweise, das ist eher eine lästige aber doch notwendige Pflichtübung. Viel interessanter ist das entwickeln der Schnittstellen von den Komponenten, auch der Kommunikation zwischen den Komponenten. Halt der ganze Beziehungs- Hick Hack.

Wo rauf ich hinaus will:
OOP ist eher eine Philosophie!
Eine gänzlich andere Herangehensweise, an die Dinge.

Wenn man die Philosophie verinnerlicht hat, man es lernt in diesen Strukturen zu denken, dann entwickeln sich die Verfahrensweisen automatisch. Es macht wenig Sinn, die Verfahren auswendig zu lernen, ohne das Warum verstanden zu haben.

Und das vermisse ich bei dem Autor!
Er beschreibt einen winzigen Teil der Verfahren, nicht die Philosophie, welche das Ganze erst sinnvoll macht.

Aber es gibt auch evtl. die Möglichkeit, sich über die Verfahren dem Sinn zu nähern.

Wenn dich Verfahren interessieren, dann lese die vielen Wiki Artikel zu den "OOP Design Pattern". Nicht alles ist im Arduino Umfeld 1:1 umsetzbar. Aber es zeigt dir möglich Probleme, auf die du stoßen wirst, und halbwegs standardisierte Verfahren, damit umzugehen.

Manches mal findet man in Library Code, im Klassennamen, oder in den Kommentaren z.B. die Worte  "Adapter", "Singleton", "Facade", oder auch "dependency Injection". Alles Dinge die man bei den Pattern findet und dort hinreichend erklärt werden.

--
Meiner Erfahrung nach, und ich habe schon ein paar Menschen dabei beobachten/helfen dürfen, ist es für Anfänger leichter die OOP im Kern zu verstehen, als für Wechsler von prozeduralen Sprachen/Sichtweisen.


Die prozedurale Denke, muss über Bord geworfen werden.
Vorher wird das eher nichts.
Es werden sonst nur prozedurale Programme im OOP Mäntelchen.
Wer seine Meinung nie zurückzieht, liebt sich selbst mehr als die Wahrheit.

Quelle: Joseph Joubert

combie

Quote
Obwohl ich von OOP auf Arduino nicht überzeugt bin,
Man kann natürlich daraus eine Glaubensfrage machen, und sich dann den Kopf deswegen einschlagen.
Hat durchaus Tradition.

Oder anders:
Im Grunde ist es egal, ob man mit Messer und Gabel, Stäbchen oder mit den Fingern isst, solange hinten das gleiche raus kommt.
Es ist nur eine Frage der Kultur, keine grundsätzliche.


Aber, was fehlt dir zu der Überzeugung?
Denn faktisch, damit umgehen, tust du doch schon, seit du das erste mal Serial.begin() geschrieben hast.
Wer seine Meinung nie zurückzieht, liebt sich selbst mehr als die Wahrheit.

Quelle: Joseph Joubert

agmue

Da vom TO wohl nichts mehr kommt, tobe ich mich mal aus, na, ein bischen.

Man kann natürlich daraus eine Glaubensfrage machen, und sich dann den Kopf deswegen einschlagen.
Hat durchaus Tradition.
Ja, leider, eine sehr lange. Meist hat es wohl mit Macht und Machtmißbrauch zu tun. Es ist ein Teil von uns, wir haben die Wahl.

Aber, was fehlt dir zu der Überzeugung?
Erstmal ist es ein Gefühl. Nach Paul Watzlawick (Anleitung zum Unglücklichsein) mischen sich alte und neue Erfahrungen, überlebenswichtig gegenüber dem Säbelzahntiger, macht aber Objektivität unmöglich.

Als ich das erste Mal von OOP und Vererbung las, dachte ich, die Erfinder haben einen an der Waffel, das wird nichts. War das Ausdruck meiner intellektuellen Beschränktheit? Wegen des merkwürdigen Umgangs mit Zeichenketten habe ich einen C-Kurs abgebrochen, schien mir verschwendete Zeit.

Da C++ Verwendung findet, sind andere Leute ganz offensichtlich anderer Meinung. Die fehlende Erfahrung macht diesen unbekannten Kram nicht sympathischer.

Ich habe ja mit dem ATtiny85 angefangen. Wenn der Compiler dann Konstanten wegoptimiert, dann freut mich das. Bei einem Feld mit Konstanten geht das schon nicht mehr, bei einer Struktur wohl auch nicht. Das riecht nach Verschwendung. Dafür lassen Felder Schleifen mit indexiertem Zugriff zu, das spart Programmzeilen. Ab wie vielen Konstanten lohnt ein Feld? OOP scheint dann die Steigerung zu sein, weil gleich ganze Strukturen/Klassen mit Variablen, Konstanten, Methoden und Konstruktoren kopiert werden. Auf Großrechnern mag das vertretbar sein, aber auf einem kleinen, speicherarmen Arduino? Natürlich gibt es Zeiger und Referenzen, muß man aber aufpassen.

Denn faktisch, damit umgehen, tust du doch schon, seit du das erste mal Serial.begin() geschrieben hast.
Dinge zu wiederholen, die man schon immer getan hat, wird mir mit der Zeit langweilig. Darum suche ich nach neuen Wegen. Dazu müssen alte Gefühle, Irrtümer und Halbwahrheiten zur Seite geräumt werden, was nicht einfach ist.

Beim endlichen Automaten hat die Begeisterung sofort gezündet. OOP hingegen gestaltet sich zäh. Bei Beiträgen zu diesem Thema schlackere ich meist mit den Ohren, eigene Versuche, wie beispielsweise ein Feld im Konstruktor, enden gelegentlich im Chaos. Da mischt sich dann die Frage, ob OOP auf dem Arduino sinnvoll ist mit der Frage, inwieweit es für mich erstrebenswert ist.

Meine Aussage ist subjektiv formuliert und auch so gemeint. Hilft niemandem, interessiert niemanden, aber Du hast gefragt, da wollte ich doch wenigstens eine Antwort versuchen.
Die Vorstellungskraft ist wichtiger als Wissen, denn Wissen ist begrenzt. (Albert Einstein)

Klaus_ww

Quote
Da vom TO wohl nichts mehr kommt
Leute, seid doch mal gnädig und denkt auch an die Menschen, die neben der Bastelei noch Job und ein Leben haben UND nicht den lieben langen Tag hier im Forum rumwurschteln können oder wollen.

Ich habe eure fast schon philosophisch anmutenden Beiträge aufmerksam gelesen und agmues heutige Ausführungen beinhalten viel von meinem Gefühl bei der Sache.

Meine Ansprüche an mir innewohnende Programmierkünste sind moderat und wenn ein Programm das tut was es soll ist es für mich ein gutes Programm.
Trotzdem will ich mal über den Tellerrand blicken und auch ohne praktischen Anlaß meinen Verständnishorizont erweitern. Um nichts anderes ging es hier.

Ich empfinde die OOP erst mal als eine Erweiterung von Funktionen, die aber ungleich flexibler zu handhaben sind. Ob das auf den kleinen Controlern Sinn macht oder nicht kann ich nicht beurteilen, aber angewandt wird es wie erwähnt ja bei den zahlreichen Libs offenbar konsequent.

Freizeit-Programmierer mit moderatem Ehrgeiz besseren Code zu schreiben.

agmue

Leute, seid doch mal gnädig ...
Wollte Dir nicht auf die Füße treten, nur andeuten, warum ich etwas gewartet habe mit meinem Beitrag.

Munter geht's weiter :)
Die Vorstellungskraft ist wichtiger als Wissen, denn Wissen ist begrenzt. (Albert Einstein)

Serenifly

Bei einem Feld mit Konstanten geht das schon nicht mehr, bei einer Struktur wohl auch nicht.
Der Fehler ist zu denken dass const immer eine Konstante im Flash anlegt. Das ist eher ein Nebeneffekt unter gewissen Umständen. Erst mal heißt es dass man nur lesend darauf zugreifen kann

Quote
weil gleich ganze Strukturen/Klassen mit Variablen, Konstanten, Methoden und Konstruktoren kopiert werden.
Wissen wann und wie Kopien erzeugt werden gehört zu den OOP Grundlagen.

Aber auch ohne OOP zu kennen sollte man das wissen. So sieht man von Anfängern immer wieder solchen Blödsinn:
Code: [Select]

void function(String str)

combie

Quote
So sieht man von Anfängern immer wieder solchen Blödsinn:
Ein unabsichtliche Kopie, ist als böse anzusehen.
Eine Absichtliche kann einen Zweck erfüllen und damit notwendig sein.


Quote
Bei einem Feld mit Konstanten geht das schon nicht mehr, bei einer Struktur wohl auch nicht.
Das hat natürlich nichts mit OOP zu tun.
Aber dennoch geht das.
Beispiel:
Am Anfang meiner CombiePin finden sich Arrays, welche zu 100% weg optimiert werden.


Quote
OOP scheint dann die Steigerung zu sein, weil gleich ganze Strukturen/Klassen mit Variablen, Konstanten, Methoden und Konstruktoren kopiert werden. Auf Großrechnern mag das vertretbar sein, aber auf einem kleinen, speicherarmen Arduino?
Da irrst du, zumindest ein wenig.
Wenn man Objekte klont, werden die Datenbereiche kopiert.
Das ist allerdings auch nötig. Würde man auch abseits der OOP machen müssen.
Methoden werden nicht kopiert!
Die liegen nur einmal im Speicher vor. Egal wie oft  kopiert, oder vererbt wird.
Ausnahme: Virtuelle Methoden.
Die benötigen zusätzlich einen Zeiger im Flash, also auf einem AVR 2 Byte

Auch hier kann die CombiePin ein Beispiel sein.
Pin initialisieren und togglen benötigt 6 Byte im Programmspeicher (3 Assemblerstatements) und kein Byte Ram. Trotz OOP incl. Vererbung.

Dass OOP Ressourcen fressend ist, ist ein gern erzähltes Märchen.
Allerdings erlaubt auch das OOP Paradigma schlampigen Code/Entwicklungen. Dann kann das natürlich zutreffen, sogar sehr gründlich. Aber das sollte man dann nicht der OOP an sich anlasten. Das wäre ungerecht(denke ich mal).

Quote
Da mischt sich dann die Frage, ob OOP auf dem Arduino sinnvoll ist mit der Frage, inwieweit es für mich erstrebenswert ist.
In Punkt 1 kann ich dich beruhigen!
Dem µC ist es egal, ob OOP, oder nicht.

Punkt 2 ist interessanter!
Den kann "ich" dir natürlich nicht beantworten...
Ich kann dich bestenfalls ein paar Meter auf dem Weg begleiten und in die "richtige" Richtung stubsen.

Vielleicht sollten wir hier die CombiePin mal durch gehen. Allzu umfangreich ist sie ja nicht.
Nicht nur "Was" es tut. sondern eher, "Warum" ich es genau so gemacht habe, wie es jetzt da steht.
evt. zündet dann etwas....
(und vielleicht verhilft mir das auch noch zu ein paar Zündern)



Quote
Ich empfinde die OOP erst mal als eine Erweiterung von Funktionen, die aber ungleich flexibler zu handhaben sind. Ob das auf den kleinen Controlern Sinn macht oder nicht kann ich nicht beurteilen, aber angewandt wird es wie erwähnt ja bei den zahlreichen Libs offenbar konsequent.
Konsequent!
Als interessantes Beispiel, möchte ich mal die EEPROM.h anführen.

Quote
und agmues heutige Ausführungen beinhalten viel von meinem Gefühl bei der Sache.
Das kann ich mir gut vorstellen!
Ihr scheint beide ähnliche Hürden vor euch zu haben.

Die ultimative Lösung kann ich nicht bieten, da ich nicht weiß, wo es klemmt.
Aber ich weiß, dass es eine Frage der Einstellung ist.
Der inneren Ausrichtung.

Ich kann ja mal erzählen, wie ich zur OOP gekommen bin...
Damals, hatte ich viel Kontakt mit Bienen.
Und irgendwann zündete es!
Ich will Programme schreiben, die sich wie ein Bienenvolk verhalten.
(Mein Nickname Combie kommt daher: Von "Computer Bienen")
Viele einzelne Elemente/Bienen/Objekte, welche als Ganzes, mehr sind, als die bloße Summe.
Jede einzelne Biene ist recht doof.
Recht begrenzt.
Hat allerdings recht klare Schnittstellen (zumindest für Bienen), auch zur Kommunikation mit anderen Bienen.

Seit dem eifere ich dem Ziel hinterher.
Erst viel später habe ich erfahren dass es das Wort OOP dafür gibt!
Und bin dann auf OOP Sprachen umgestiegen.

C++ ist mir zuerst begegnet, als es noch "C mit Klassen" hieß.
Fürchterlich!
Mit dem heutigen C++ kaum noch zu vergleichen.

Quote
Trotzdem will ich mal über den Tellerrand blicken und auch ohne praktischen Anlaß meinen Verständnishorizont erweitern. Um nichts anderes ging es hier.
Habe ich durchaus Verständnis für!

Sollen wir die CombiePin mal durchgehen?
Da sind durchaus einige Konzepte verarbeitet, welche sich wie ein roter Faden durch die OOP im allgemeinen ziehen.
Klar, hier spezialisiert auf Schnelle ein und Ausgabe, und von daher ein Sonderfall.
Das Ziel war nicht, Daten und Code in ein Klassenkorsett zu quetschen. Das scheint mir eine der ersteren Fehlannahmen von OOP Anfängern zu sein, dass das das Ziel sein muss.
Ist es nicht. Eine mögliche/häufige Begleiterscheinung, ja. Aber nicht das Ziel.
Das Ziel, oder das "Warum" lautet eher: Kapselung!
Darum ist es auch so, dass Code und Daten, bei der Entwicklung, automatisch zueinander finden.


Natürlich können wir auch einen beliebigen anderen Code zerlegen, und versuchen herauszufinden, was sich der Autor dabei gedacht hat.
(Nur bei der CombiePin, weiß ich das "Warum" genau)

Wenn OOP lernen, dann würde ich vorschlagen, sich eher auf das "Warum wird das so gemacht", zu konzentrieren, als auf das "Wie". Denn die abstrakten Konzepte müssen geübt werden, dann kommt das "Wie" fast von selber.

Wer seine Meinung nie zurückzieht, liebt sich selbst mehr als die Wahrheit.

Quelle: Joseph Joubert

uxomm

Sollen wir die CombiePin mal durchgehen?
Ich wäre dabei sicher ein interessierter Mitleser.
Always decouple electronic circuitry.

eMeS

Wo ich bin ist nichts - doch überall kann ich nicht sein!

Go Up