Einführung Klassen - Welche Inhalte gehören noch dazu?

Gute Links und Tutorials könnt ihr hier posten.
Antworten
MADI'S Tech
User
Beiträge: 10
Registriert: Freitag 1. Mai 2020, 18:43

Hallo liebes Python Forum,

da Python u.A. eine objektorientierte Sprache ist, will ich das Thema 'Klassen' verstehen und richtig anwenden können (z.B. für das OOP).
Ich hab dazu schon Tutorials auf YouTube hochgeladen:
  • Ein Tutorial zu String Representation kommt am 8.8.
Sollte ich in den Videos was falsches gesagt haben, oder Ergänzungen notwendig wären, teile es mir in den Kommentaren bitte mit (Idealerweise unter dem jeweiligen Video auf YouTube).
Von meinen Fehlern lerne nicht nur ich, sondern auch andere Anfänger.

Neben den Inhalten in den oben aufgezählten Tutorials, was sollte ich mir noch unbedingt anschauen/nachlesen/aneignen über Klassen in Python? (Entsprechende Links zu Docs, Nachschlagewerken und Tutorials wären ideal)

Vielen Dank!
Vom Pogrammierneuling zum Profi!

Ich dokumentiere meinen (Irr-)Weg in der Pogrammiersprache Python:
Youtube - MADI'S Tech
Twitch - MADIS_Tech
Twitter - @MadisTech
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

Das eine Programmiersprache objektorientiert ”ist”, bedeutet nicht, dass sie Klassen haben muss. Gegenbeispiele wären Io und JavaScript bis es tatsächlich Klassen als Sprachkonstrukt bekommen hat. Und auch in Programmiersprachen wie C kann man objektorientiert programmieren. Nur halt ohne spezielle Unterstützung der Programmiersprache.

Ich finde die Aufteilung ungünstig weil da viel gezeigt wird was man so nicht macht. Also nicht nur das man das nicht macht, man sollte das auch nicht machen. Es wird also falsches gezeigt. Und das auch noch ohne zu sagen dass das falsch ist.

Attribute werden in der `__init__()` eingeführt. Nicht in anderen Methoden und schon gar nicht von aussen einfach gesetzt.

Auf Klassenebene gehören in der Regel nur Konstanten, die dann auch entsprechend KOMPLETT_GROSS geschrieben werden.

Die Methode sollte kein `auto` im Namen haben, also nicht noch mal den Klassennamen wiederholen. Denn das es sich um die Info(ausgabe) eines Autos handelt, ist ja schon dadurch klar, dass die Methode zur Klasse `Auto` gehört.

Das komplette Video sollte neu gemacht werden ohne den Fehler das die ganze Zeit bis 3:04 `self` gar nicht benutzt wird, sondern da hart das `pkw` von der Modulebene benutzt wird. Statt das an der Stelle dann einfach versuchen ”unbemerkt” zu ändern.

Schönes Beispiel warum auf Modulebene keine Variablen stehen sollten, denn wenn das Hauptprogramm in einer Funktion stehen würde, hätte man diesen Fehler sofort beim ausführen bemerkt.

Das `staticmethod()` ist komisch. Ja das ist syntaktisch so alles richtig, aber Null Erklärung warum man das (nicht) macht ist für Anfänger nicht sinnvoll. Wenn man kein `self` verwendet, dann ist das keine Methode sondern eine Funktion. Und Funktionen haben in der Regel in Klassen nix zu suchen. Man muss also schon eine gute Erklärung parat haben warum man das nicht einfach ausserhalb der Klasse definiert.

`classmethod()` wird dagegen nicht erwähnt/erklärt, obwohl das für ”alternative Konstruktoren” erst einmal relevanter ist als `staticmethod()`.

Das erste Video hätte man sich sparen können und gleich mit einer Klasse + `__init__()`-Methode anfangen sollen.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
MADI'S Tech
User
Beiträge: 10
Registriert: Freitag 1. Mai 2020, 18:43

__blackjack__ hat geschrieben: Freitag 7. August 2020, 16:47 Das eine Programmiersprache objektorientiert ”ist”, bedeutet nicht, dass sie Klassen haben muss. Gegenbeispiele wären Io und JavaScript bis es tatsächlich Klassen als Sprachkonstrukt bekommen hat. Und auch in Programmiersprachen wie C kann man objektorientiert programmieren. Nur halt ohne spezielle Unterstützung der Programmiersprache.
Danke für den Hinweis!
__blackjack__ hat geschrieben: Freitag 7. August 2020, 16:47 Ich finde die Aufteilung ungünstig weil da viel gezeigt wird was man so nicht macht. Also nicht nur das man das nicht macht, man sollte das auch nicht machen. Es wird also falsches gezeigt. Und das auch noch ohne zu sagen dass das falsch ist.
Geben Sie mir bitte belastbare Quellen, die Ihre Ansicht bestätigen. Die Syntax definiert, was 'falsch' ist und was nicht.
"[...] ohne zu sagen dass das falsch ist."
Ich mach mir nicht die Mühe, Videos zu produzieren, mit der Absicht, bewusst, Falschaussagen zu tätigen. Betrachten Sie bitte die Inhalte im Kontext des Kanals. Sachliche Fehler solle man bitte in der Kommentarfunktion aufzeigen und erklären, idealerweise mit Referenzen und Quellen. Das hilft nicht nur mir, sondern jedem, der auch Anfänger ist und sich verbessern will.
__blackjack__ hat geschrieben: Freitag 7. August 2020, 16:47 Attribute werden in der `__init__()` eingeführt. Nicht in anderen Methoden und schon gar nicht von aussen einfach gesetzt.
__blackjack__ hat geschrieben: Freitag 7. August 2020, 16:47 Das erste Video hätte man sich sparen können und gleich mit einer Klasse + `__init__()`-Methode anfangen sollen.
Ich habe bewusst diese Vorgehensweise gewählt, um mich Schritt-für-Schritt dem Thema 'Klassen' anzunähern, die Syntax erlaubt es.
__blackjack__ hat geschrieben: Freitag 7. August 2020, 16:47 Auf Klassenebene gehören in der Regel nur Konstanten, die dann auch entsprechend KOMPLETT_GROSS geschrieben werden.
In erster Linie will ich, dass das Pogramm macht, was es soll. Positive Feedback-Loops motivieren im Lernprozess.
__blackjack__ hat geschrieben: Freitag 7. August 2020, 16:47 Die Methode sollte kein `auto` im Namen haben, also nicht noch mal den Klassennamen wiederholen. Denn das es sich um die Info(ausgabe) eines Autos handelt, ist ja schon dadurch klar, dass die Methode zur Klasse `Auto` gehört.

Das komplette Video sollte neu gemacht werden ohne den Fehler das die ganze Zeit bis 3:04 `self` gar nicht benutzt wird, sondern da hart das `pkw` von der Modulebene benutzt wird. Statt das an der Stelle dann einfach versuchen ”unbemerkt” zu ändern.

Schönes Beispiel warum auf Modulebene keine Variablen stehen sollten, denn wenn das Hauptprogramm in einer Funktion stehen würde, hätte man diesen Fehler sofort beim ausführen bemerkt.

Das `staticmethod()` ist komisch. Ja das ist syntaktisch so alles richtig, aber Null Erklärung warum man das (nicht) macht ist für Anfänger nicht sinnvoll. Wenn man kein `self` verwendet, dann ist das keine Methode sondern eine Funktion. Und Funktionen haben in der Regel in Klassen nix zu suchen. Man muss also schon eine gute Erklärung parat haben warum man das nicht einfach ausserhalb der Klasse definiert.

`classmethod()` wird dagegen nicht erwähnt/erklärt, obwohl das für ”alternative Konstruktoren” erst einmal relevanter ist als `staticmethod()`.
Meine Antwort darauf findet man im Kommentarbereich HIER.
Vom Pogrammierneuling zum Profi!

Ich dokumentiere meinen (Irr-)Weg in der Pogrammiersprache Python:
Youtube - MADI'S Tech
Twitch - MADIS_Tech
Twitter - @MadisTech
DasIch
User
Beiträge: 2718
Registriert: Montag 19. Mai 2008, 04:21
Wohnort: Berlin

Falsch ist vielleicht ein etwas harter Begriff aber der Anspruch sollte doch schon etwas höher sein als die Syntax erlaubt es. Man möchte den Code ja auch lesen und verstehen können. Fehler schnell finden und beheben können, sowie vielleicht auch nochmal neue Funktionalität hinzufügen können, selbst wenn man den Code jetzt eine ganze Weile nicht gesehen hat.

Ein Anfänger möchte vielleicht auch einmal das Wissen praktisch nutzen. Indem man bei Open Source Projekten etwas beiträgt z.B. oder vielleicht wie deine Signatur verspricht zum Profi werden. Letzteres wird schwierig wenn man gelernt hat Code in einer Art und Weise zu schreiben, die beim Gegenüber im Vorstellungsgespräch zwangsläufig auf Ablehnung stoßen wird.
nezzcarth
User
Beiträge: 1632
Registriert: Samstag 16. April 2011, 12:47

MADI'S Tech hat geschrieben: Samstag 8. August 2020, 16:40 Die Syntax definiert, was 'falsch' ist und was nicht.
Das kann man so meiner Meinung nach so strikt nicht sagen. Denn gerade bei Python gibt es sehr viele (und in der Regel gut begründete) Konventionen und Best Practices mit den Freiheiten, die die Sprache auf den ersten Blick bietet, umzugehen und an die man sich halten sollte. Einige davon sind sogar festgeschrieben, zum Beispiel die Benennungskonventionen in PEP8. Das alles zu lernen gehört meiner Meinung nach genau so dazu, wie sich die Syntax anzueignen.
MADI'S Tech
User
Beiträge: 10
Registriert: Freitag 1. Mai 2020, 18:43

DasIch hat geschrieben: Samstag 8. August 2020, 17:29 der Anspruch sollte doch schon etwas höher sein als die Syntax erlaubt es.
Berechtigte Kritik. Ich fang lieber bei den absoluten Grundlagen an und will die Basics der Sprache verstehen und das ist nunmal die Syntax.
DasIch hat geschrieben: Samstag 8. August 2020, 17:29 Man möchte den Code ja auch lesen und verstehen können. Fehler schnell finden und beheben können, sowie vielleicht auch nochmal neue Funktionalität hinzufügen können, selbst wenn man den Code jetzt eine ganze Weile nicht gesehen hat.
Hmm. Da das, was ich an Code schreibe, recht überschaubar ist, bin ich nie auf diese Probleme gestoßen.
DasIch hat geschrieben: Samstag 8. August 2020, 17:29 Ein Anfänger möchte vielleicht auch einmal das Wissen praktisch nutzen. Indem man bei Open Source Projekten etwas beiträgt
Guter Einwand. Da meine derzeitigen Ziele, die ich mit dieser Sprache für die Anwendung habe, das Beitragen an Open Source Projekten ausschließen, sind für mich persönlich Schreibkonventionen Gegenstand kritischer Betrachtung. Ich bin nicht jemand, der blind Dogmen folgt. Diese Konventionen machen aber Sinn, wenn man mit anderen an einem Projekt arbeitet, um Missverständnissen vorzubeugen und eine personenübergreifende konsistente Pogrammstruktur etablieren möchte.
DasIch hat geschrieben: Samstag 8. August 2020, 17:29 z.B. oder vielleicht wie deine Signatur verspricht zum Profi werden.
Es bezieht sich auf mich und ist kein Versprechen an andere. Reißerischer Titel, ich weiß. :wink:
Ich dokumentiere lediglich meinen Bildungs(bzw. Irr-)weg in Python. Ich lade herzlich dazu ein, meine Inhalte konstruktiv zu kritisieren.
DasIch hat geschrieben: Samstag 8. August 2020, 17:29 Letzteres wird schwierig wenn man gelernt hat Code in einer Art und Weise zu schreiben, die beim Gegenüber im Vorstellungsgespräch zwangsläufig auf Ablehnung stoßen wird.
Berechtigte Kritik. Wie schon oben erwähnt, ich fang lieber ganz weit unten an und arbeite mich Stück für Stück hoch. Ich habe derzeit nicht die Absicht, mich als Softwareentwickler zu bewerben.
nezzcarth hat geschrieben: Samstag 8. August 2020, 17:38 Das kann man so meiner Meinung nach so strikt nicht sagen.
Gibt es in Python keine strikte Trennung zwischen 'falsch' und 'nicht falsch' (Ich wähle hier bewusst 'richtig' nicht!)?
Ich hab einen ingenieurstechnischen Hintergrund. Dort entscheided die Physik, ob etwas 'falsch' oder 'nicht falsch' ist.
nezzcarth hat geschrieben: Samstag 8. August 2020, 17:38 Denn gerade bei Python gibt es sehr viele (und in der Regel gut begründete) Konventionen und Best Practices mit den Freiheiten, die die Sprache auf den ersten Blick bietet, umzugehen und an die man sich halten sollte.
Mir wurden da auch schon konkret Beispiele gezeigt, die ich mir schon angeignet habe, weil diese, für meine Zwecke, Sinn gemacht haben. Ich bin kein Freund davon, etwas zu machen, nur weil 'es halt so ist'.
nezzcarth hat geschrieben: Samstag 8. August 2020, 17:38 Einige davon sind sogar festgeschrieben, zum Beispiel die Benennungskonventionen in PEP8. Das alles zu lernen gehört meiner Meinung nach genau so dazu, wie sich die Syntax anzueignen.
Danke für den Link! Die Quelle hab ich mir mal notiert.



Gibt es speziell zum Thema 'Klassen', eurer Meinung nach, dass ich noch anschauen sollte?
Vom Pogrammierneuling zum Profi!

Ich dokumentiere meinen (Irr-)Weg in der Pogrammiersprache Python:
Youtube - MADI'S Tech
Twitch - MADIS_Tech
Twitter - @MadisTech
Benutzeravatar
kbr
User
Beiträge: 1487
Registriert: Mittwoch 15. Oktober 2008, 09:27

Mit „zum Thema Klassen anschauen“ möchtest Du Dich wahrscheinlich der objekt-orientierten Programmierung annähern. Diese geht aber weit über die reine Syntax hinaus und braucht Zeit, gute Lehrer und viel Übung um sie irgendwann gut zu beherrschen. Zur Prüfung, ob man etwas verstanden hat, Ist nichts besser geeignet, als der Versuch, es anderen zu erklären. Von daher stammen Deine Videos aus einer richtigen Idee, jedoch mit dem Nachteil, dass sie sich nicht an einen kleinen Kreis richten, in dem sich interaktiv kommunizieren lässt und in dem gemeinsam Fragen und Verständnisprobleme diskutiert werden können. Statt dessen steht es als Tutorial anderen zur Verfügung, die noch weniger wissen, hoffen etwas zu lernen, und die Inhalte möglicherweise als vorbildlich betrachten. Das Web ist mittlerweile voll von solchen Tutorials. Das wäre meine Kritik, die Dich sicherlich nicht freut, denn es wird Dich vermutlich einige Zeit gekostet haben, die Videos zu erstellen. Aber zum Lernen und für Fragen sind Foren wie dieses die bessere Wahl - oder lokale Usergroups.
Benutzeravatar
__blackjack__
User
Beiträge: 13004
Registriert: Samstag 2. Juni 2018, 10:21
Wohnort: 127.0.0.1
Kontaktdaten:

@MADI'S Tech: Doch, Du bist auch bei diesem kleinen Auto-Beispiel schon auf ein Problem gestossen was mit ein Grund dafür ist, dass auf Modulebene nur Code stehen sollte der Konstanten, Funktionen, und Klassen definiert, und keine Variablen. Wenn man dann in einer Methode eine Variable von der Modulebene verwendet, scheint das zu funktionieren, solange man das nur mit einer Variablen macht. Das ist aber extrem unübersichtlich und damit fehleranfällig, selbst wenn es denn gewollt gewesen wäre.

Es gibt einen Unterschied zwischen blind Dogmen zu folgen auf der einen Seite, und erst einmal einfach alles zu hinterfragen und erst zu befolgen wenn es einem jemand erklärt hat, vielleicht, wenn man Lust hat, auf der anderen Seite. Das ist die falsche ”Default”-Einstellung. Damit eckt man nicht nur unnötig in einer Community an, sondern man gewöhnt sich auch falsche Sachen an, die man sich später dann erst wieder abgewöhnen muss, wenn man verstanden hat *warum* etwas in der Sprache so gemacht wird, und beispielsweise nicht so wie man das aus einer anderen Sprache kennt. Und selbst wenn man es nicht versteht, oder es anders sieht, sollte man sich immer noch überlegen ob man da wirklich gegen verstossen muss.

Du kannst Dich auch nicht damit herausreden das Du Dich nicht an Konventionen halten müsstest weil die nur in Projekten mit mehreren Personen Sinn machen, denn Du diese Konventionen dienen der besseren Kommunikation und wenn Du Code öffentlich in Foren oder Videos *kommunizierst*, dann greift der Grund für die Konventionen ja bereits.

Bei Python, und auch bei anderen modernen Sprachen, ist das auch nicht mehr so, dass es da wirklich viele verschiedene Konventionen gibt und man bei jedem Projekt erst einmal schauen muss, welche da beispielsweise für Namenschreibweisen oder Kennzeichnung von Blöcken gilt. Bei C oder C++ kann das noch sehr variieren, wie man beispielweise Funktions- oder Methodennamen schreibt, oder wie Blöcke nun genau formatiert werden. Bei Java ist die Frage nach den Namenschreibweisen dagegen wirklich allgemein geklärt, auch wenn dem Compiler im Grunde egal ist ob man Klassennamen nun mit einem Grossbuchstaben anfängt, oder ob man statt `camelCase` `unterstriche_in_namen` verwendet. Auf die Idee würde niemand ernsthaft kommen. Das wäre syntaktisch korrekt, trotzdem wird Dir jeder Java-Programmierer sagen das ist *falsch*.

Und bei Python ist das PEP8 und bestimmte Sachen die im Grunde jeder Python-Programmierer als ”unpythonisch” sieht. Beispielsweise iterieren über einen Index nur um damit auf eine Sequenz zuzugreifen, statt direkt über die Elemente der Sequenz zu iterieren. Oder eine Liste mit Dummywerten anzulegen und danach mit einer Schleife (+ Index) die Dummywerte der Reihe nach durch den tatsächlichen Wert zu ersetzen. Das sind Muster die beispielsweise gerne von BASIC, C, oder Pascal-Programmierern versucht werden, weil man so etwas in der Richtung in *den* Sprachen mit Arrays macht. Und damit ist das ”unpythonisch”, weil das kein idiomatisches Python ist. Idiome gehören auch zu Programmiersprachen und trennen richtigen und falschen Code, selbst wenn der falsche Code das richtige Ergebnis liefert.

Das ist auch in anderen Programmiersprachen so. Wenn jemand in C++ wie in C programmiert, also beispielsweise mit Arrays und Pointern statt mit STL-Containern und -Iteratoren und Smartpointern arbeitet, wird ein C++-Programmierer sagen das ist falsch, weil kein idiomatisches C++. Wenn jemand Java wie in Pascal programmiert, also beispielsweise statische Methoden als Prozeduren und Funktionen und Klassen nur als RECORD's einsetzt, statt echte Klassen und Methoden zu verwenden, wird ein Java-Programmierer sagen das ist falsch, weil kein idiomatisches Java.

Auch in der angewandten Physik etscheiden nicht nur die physikalischen Gesetze ob etwas richtig oder falsch gelöst ist. Man kann eine Sicherung durch ein Stück Draht ersetzen wenn man nix anderes hat, oder es nervt, dass die dauernd rausfliegt, und das kann problemlos funktionieren. Ist aber falsch. Es gibt auch dort „best practices“ die Fehler verhindern helfen sollen. Kabelfarben kann man ja eigentlich völlig beliebig wählen, so wie man Namen in Programmen beliebig wählen kann. In Formeln kann man Namen eigentlich auch beliebig wählen, also nennen wir den Strom mal Z, die Spannung R, und den Widerstand mal spasseshalber mit einem kleinen j. Und nun sag mal einem Physiker das `R = jZ` doch eigentlich gar nicht falsch ist. Halt nur ein bisschen unkonventionell — man will sich da nicht blind an Dogmen halten. Ich glaube nicht das man damit weit kommt und/oder das man gar Anfängern so etwas vorleben sollte.
“Most people find the concept of programming obvious, but the doing impossible.” — Alan J. Perlis
Antworten