Forum: PC-Programmierung OOP & Klassen, aber wie?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Tim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Momentan unternehme ich erste Programmierschritte in Python und denke, 
die eigentlichen Grundlagen verstanden zu haben, einschließlich OOP, 
Klassen und Methoden.
Was ich aber überhaupt nicht verstehe: Woher weiß ich wie ich meinen 
Code in welche Klassen und Methoden zu unterteilen habe?

(ich möchte in Kodi ein Video-Addon programmieren, das vom Umfang her 
kaum mehr als Skripte sind, ausgedruckt weniger als ein Dutzend DIN 
A4-Seiten. Bis jetzt ist das alles nur mit Funktionen programmiert, das 
funktioniert, scheint aber unschön zu sein. Als Vorlage dient 
https://github.com/romanvm/plugin.video.example).

von Matthias S. (da_user)


Bewertung
-1 lesenswert
nicht lesenswert
Tim schrieb:
> Was ich aber überhaupt nicht verstehe: Woher weiß ich wie ich meinen
> Code in welche Klassen und Methoden zu unterteilen habe?

Erfahrung.

Prinzipiell sollen die "tiefsten" Klassen und Methoden möglichst 
unspezifisch sein. Mit jeder weiteren Schicht wirds dann spezifischer.
Auch sollte die sich das, was eine Methode tut mit einem möglichst 
passenden Verb beschreiben lassen - welches dann auch für den 
Methodennamen verwendet werden soll.
Also statt
doWork()
lieber
read()
parse()
sort()
write()

Hintergründe sind einerseits, dass man unspezifischere Klassen & 
Methoden evtl. für was anderes wiederverwenden kann.
Und es vereinfacht die Fehlersuche. Wenn z.B. bei obigen Beispiel die 
Werte nicht richtig sortiert sind, sucht man in der "sort" Methode. 
Wahrscheinlich bequemer als 3/4 der "doWork" Methode durchzuarbeiten.

BTW: Buchempfehlung: Weniger schlecht programmieren - von Katarina 
Passig u.A.

: Bearbeitet durch User
von was (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Tim schrieb:
> Bis jetzt ist das alles nur mit Funktionen programmiert, das
> funktioniert, scheint aber unschön zu sein.

Also hast du funktionierenden Code, den du jetzt schöner machen willst? 
Das ist doch eine dankbare Ausgangsituation zum lernen.

Hast du mehrere nahezu identische Codeabschnitte? -> In eine Methode 
packen, die kleinen Unterschiede über Parameter handeln.

Tim schrieb:
> Woher weiß ich wie ich meinen
> Code in welche Klassen und Methoden zu unterteilen habe?

Wie Matthias sagt, Erfahrung. Es gibt nicht die eine Schritt-für-Schritt 
Anleitung. Das Ziel sollte eben sein, dass du den Überblick nicht 
verlierst und auch in ein paar Monaten wieder verstehst, wie dein Code 
funktioniert.

Das heißt nicht unbedingt, dass man sich auf Zwang irgendwelche Klassen 
aus den Fingern saugen muss.
Eine Klasse die nichts repräsentiert ist das Äquivalent zur 
Krimskrams-Schublade im echten Leben. Sieht aus als hätte man 
aufgeräumt, macht Dinge wiederzufinden aber nicht einfacher.

von Heiner (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tim schrieb:
> Was ich aber überhaupt nicht verstehe: Woher weiß ich wie ich meinen
> Code in welche Klassen und Methoden zu unterteilen habe?

3 Antworten dazu:

1. Python selbst stellt hier überhaupt keine Anforderungen. Das gehört 
zu den schönen Eigenschaften dieser Sprache: Ob du Klassen (oder auch 
überhaupt Funktionen) bildest, bleibt dir grundsätzlich selbst 
überlassen.

2. Sofern man auf Bibliotheken oder allgemein bereits vorhandenen Code 
aufbaut, könnte man gezwungen sein, mit Klassen zu hantieren, z.B. von 
einer bereits existierenden Klasse zu erben und dann bestimmte Methoden 
zu überschreiben. Ein einigermaßen einfaches Beispiel findest du bei 
exceptions: Wenn du eine eigene exception haben willst, musst du selbst 
etwas von der Klasse Exception (oder BaseException, aber meistens die 
falsche Wahl ...) ableiten.

3. Dann bleibt noch die Situation, dass du selbst objektorientiert 
schreiben willst. Dazu schaust du dir am besten mal Bücher zum Thema 
objektorientierte Analyse und Design an, außerdem viel möglichst realen 
Code. Ein gutes Gespür, wie fein oder grob Klassen gebildet werden 
sollten, entwickelst du nur mit Erfahrung.

von Hannes J. (Firma: _⌨_) (pnuebergang)


Bewertung
0 lesenswert
nicht lesenswert
Tim schrieb:
> Was ich aber überhaupt nicht verstehe: Woher weiß ich wie ich meinen
> Code in welche Klassen und Methoden zu unterteilen habe?

Wie schon jemand schrieb, Erfahrung. Aber nehmen wir mal die ganz alte 
Schule:

Klassen sind Baupläne für Objekte.

Objekte sind Instanzen einer Klasse.

Objekte repräsentieren (virtuell) reale oder abstrakte Dinge.

An dem Punkt kommen dann so typische Beispiele für Objekte wie Auto, 
Reifen, Rechteck, Linie, Server, Geldautomat. Praktisch heißt das, du 
siehst dir dein Problem an und arbeitest heraus welche Dinge bei deinem 
Problem eine Rolle spielen. Danach bildest du die Klassen.

Objekte kann man bitten für das Objekt typische Dinge zu tun oder Fragen 
über sich zu beantworten. Beispiel: Auto->anfahren(), Auto->bremsen(), 
Auto->welcheFarbeHastDu().

Was ein Objekt tun kann und auf welche Fragen es antworten kann wird 
durch Methoden beschrieben.

Also bekommen deine Klassen (die Baupläne für Objekte sind), jeweils die 
Methoden die für die jeweiligen Objekte typisch sind und die für die 
konkrete Problemlösung nötig sind.

Das "für das Objekt typisch" ist dabei wichtig. Viele OO-Programme 
halten sich nicht dran und es kommt Müll raus bei dem Klassen/Objekte 
nur zufällige Gruppierungen von Methoden sind.

Ebenso ist "für die konkrete Problemlösung" wichtig. Beispiel: Wenn dein 
virtuelles Auto nur fahren und anhalten können muss wirst du, weil es 
einfacher ist, keine Methoden zum Blinken oder zum Betätigen der Fenster 
schreiben.

Es geht, bis auf Ausnahmen, nicht darum ein reales oder abstraktes Ding 
vollständig im Rechner abzubilden. Ausnahmen siehst du bei Bibliotheken 
und Frameworks. Die müssen mehr anbieten als in einer einzelnen 
Anwendung benötigt wird um möglichst viele Anwendungen zu unterstützen.

von vn nn (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tim schrieb:
> Was ich aber überhaupt nicht verstehe: Woher weiß ich wie ich meinen
> Code in welche Klassen und Methoden zu unterteilen habe?

Für einfache Projekte kann es helfen, als Text auszuformulieren was man 
möchte:
Ich habe ein Auto. Ein Auto ist ein Sonderfall eines Kraftfahrzeuges. 
Ein Kraftfahrzeuges hat eine Motorleistung und kann fahren (vorwärts und 
rückwärts), lenken (rechts und links) und bremsen. Um fahren zu können, 
braucht es mindestens zwei Achsen mit jeweils mindestens einem Rad, 
mindestens eine Achse lenkbar. Ein Auto hat zwei Achsen mit zwei Rädern, 
eine davon lenkbar. Im Gegensatz zum generischen Kraftfahrzeug hat es 
auch eine Karosserie, mit Lack in einer bestimmten Farbe.

Kraftfahrzeug:
 - Eigenschaften: Leistung
 - Member: Achsen[]
 - Methoden: fahre(richtung), lenke(richtung), bremse()

Achse:
 - Member: Räder

LenkbareAchse (erbt von Achse):
 - Eigenschaften: Ausrichtung
 - Member: Räder[]
 - Methoden: lenke(richtung)

Auto (erbt von Kraftfahrzeug, implementiert Karosserie):
 - Eigenschaften: Leistung, Farbe
 - Member: Achsen[2] = { Lenkbare Achse(), Achse() }, Karosserie
 - Methoden: fahre(richtung), lenke(richtung), bremse()

Wüstenbuggy (erbt von Kraftfahrzeug):
 - Eigenschaften: Leistung
 - Member: Achsen[2] = { Lenkbare Achse(), Achse() }
 - Methoden: fahre(richtung), lenke(richtung), bremse()

Radlader (erbt von Kraftfahrzeug, implementiert Karosserie):
 - Eigenschaften: Leistung, Farbe
 - Member: Achsen[2] = { LenkbareAchse(), LenkbareAchse() }, Schaufel
 - Methoden: fahre(richtung), lenke(richtung), bremse(), 
hebeSchaufel(richtung)

Karosserie:
 - Eigenschaften: Farbe


--
Praktikabilität dieser Methode hängt vom Anwendungsfall ab.

von PittyJ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das kommt durch Erfahrung und jahrelanges Programmieren.
Erst dann kann man Abschätzen, ob die Klassenstruktur hilfreich ist oder 
mehr Probleme bei Änderungen macht.
Dazu gehört dann auch die Reflektion: "Dieses Konstrukt, was ich vor 5 
Jahren gemacht habe, war vollkommen überdimensioniert".
Bei nächsten Mal macht man es einfacher.

Ich habe z.B. bei Kollegen eine Vererbungsstruktur mit 5 Ebenen gesehen. 
Da blickt heute keiner mehr durch.
Aber das muss man erst einmal selber erleben.

von Tim (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Danke für die bisherigen Kommentare.
Welches Buch/Tutorial mit praxisnahen Beispielen käme noch infrage?
Geplante Anwendung --> umgesetzte Klassenstruktur

von Matthias S. (da_user)


Bewertung
0 lesenswert
nicht lesenswert
Wenn ich das richtig gelesen habe, willst du ja "nur" ein Kodi-PlugIn 
programmieren, bist also nicht im professionellen Umfeld unterwegs?

Dann mach dir nicht zu viele Gedanken, leg einfach mal los. Wenn du 
klein anfängst und dein Projekt nach und nach wächst, wird das auch mit 
der Klassenstruktur. Du könntest ggf. auch verraten, was du vorhast?

Auch

Matthias S. schrieb:
> Hintergründe sind einerseits, dass man unspezifischere Klassen &
> Methoden evtl. für was anderes wiederverwenden kann.

kannst du nach hinten anstellen.
Wenn du etwas aus einem Hobbyprojekt für ein anderes Projekt verwenden 
kannst gibt es folgende Möglichkeiten:

* du erinnerst dich nicht mehr daran, es schon gemacht zu haben und 
machst es neu
* du musst es sowieso anpassen, also reicht blödes Copy&Paste
* jemand anderes hat es schon besser gemacht und auf Git od. ähnl. 
veröffentlicht

Solltest du dich im prof. Umfeld bewegen, ist man wahrscheinlich sowieso 
gut beraten, sich dem existierenden aktuellen Umfeld anzupassen.

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
vn nn schrieb:
> Für einfache Projekte kann es helfen, als Text auszuformulieren was man
> möchte:

Ich will Kreise und Ellipsen zeichnen. Ein Kreis is ein sonderfall einer 
Ellipse. Moment mal, oh, shit: 
https://de.wikipedia.org/wiki/Kreis-Ellipse-Problem

von Dirk K. (merciless)


Bewertung
-1 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> vn nn schrieb:
>> Für einfache Projekte kann es helfen, als Text auszuformulieren was man
>> möchte:
>
> Ich will Kreise und Ellipsen zeichnen. Ein Kreis is ein sonderfall einer
> Ellipse. Moment mal, oh, shit:
> https://de.wikipedia.org/wiki/Kreis-Ellipse-Problem

Der TO steigt gerade in die OOP ein und du kommst
hier mit einem der kompliziertesten Probleme der
OOP daher, ganz großes Kino.

@TO Einfach mal anfangen, aus Fehlern lernt man.

merciless

von 🐧 DPA 🐧 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Die Idee hinter OOP ist ja schön, es erscheint Intuitiv, Dinge zu 
Klassifizieren, und sich zu überlegen x ist ein y, y ist ein z, etc. 
Aber Ich denke es ist wichtig von Anfang an zu verstehen, das sich eben 
nicht alles sauber auf die Weise Abbilden lässt.

In punkto Programmstrukturen baut OOP auf 3 Dinge auf:
 1) Das Kapseln/Zusammenfassen zusammengehörender Daten (Objekte)
 2) Das assoziieren auf diese anwendbarer Funktionen zu diesen 
(Methoden)
 3) Erweitern bestehender Objekte, sowie das Überschreiben derer 
Methoden und Eigenschaften. (Vererbung)

1 Würde ich zumindest bei so ziemlich allen nicht rein funktionalen 
Sprachen als essenziell betrachten.
2 Kann vor allem zusammen mit 3 sehr nützlich sein.
Aber 3 kann halt auch manchmal mehr Probleme bereiten, als es löst.

Der Zweck von dem ganzen OOP zeug ist ja eigentlich, auf intuitivem Weg 
Code dublizierung zu vermeiden, und die Codequalität und Zuverlässigkeit 
des Programms zu erhöhen. Das kann man damit oft auch recht gut machen. 
Das blöde daran ist halt nur, wenn man nicht aufpasst und es übertreibt, 
kann man sich schnell in eine Ecke designen, und grobe Designprobleme 
sind dann oft viel schwieriger zu lösen, als ein paar flache Code Bugs / 
Fehlfunktionen. Und nur um Code zusammenzufassen und übersichtlich zu 
halten, braucht man nicht unbedingt das ganze OOP und Vererbung. 
(Stichwort gemeinsamen Code in Unterfunktionen auslagern.)

Zudem bieten Sprachen heute noch unzählige andere Sprachkonstrukte, die 
auch ergänzend wirken können, und oft der stumpfen Vererbung vorzuziehen 
sind. Außerdem haben viele gute Programmierparadigmen und Strukturen, 
die mit OOP in Verbindung gebracht werden, damit eigentlich gar nichts 
zutun und können auch ohne verwendet werden.

Da ich schon mal dabei bin, will ich gleich mal Werbung für 
(Objekt-)Interfaces machen. Damit kann man angeben, man ist Interessiert 
an Daten/Objekten, mit denen man gewisse Dinge machen kann, und man kann 
angeben, bei welchen Arten von Daten/Objekten das gemacht werden kann. 
(Implementieren muss man es jeweils natürlich trotzdem noch). Oft 
braucht man dann Vererbung nicht mehr, und ist viel flexibler, weil man 
sich nicht mehr überlegen muss, was ist was, sondern einfach sagen kann, 
was kann momentan was.

Die meisten restlichen Vererbungs use-cases kann man auch loswerden, 
indem man eine ist-ein Beziehung durch eine hat-ein Beziehung ersetzt. 
Dass kann dann auch Probleme lösen, z.B. wenn unklar ist, ob X wirklich 
Y ist, wenn unabhängige Objekteigenschaften kollidieren, und vieles 
mehr.

Am Ende bleiben eigentlich nicht mehr viele Fälle übrig, in denen 
Vererbung tatsächlich die beste Lösung ist. Unglücklicherweise ist es in 
OOP Kreisen aber üblich, alles ins OOP Korsett zu zwängen, was anderes 
wäre ja falsch und schlechter Stil. Am Ende muss man sich meistens dann 
halt dem anpassen, was im jeweiligen dem Gebiet üblich ist.

Es gibt immer viele gute Lösungen, und meistens nicht nur den einen 
richtigen Weg. Man muss nur schauen, dass was man verzapft möglichst 
einfach Verständlich sowie von anderen erweiterbar/wartbar ist, und dass 
es auch zuverlässig Funktioniert. In der Regel ist am Ende weniger oft 
mehr.

von Heiner (Gast)


Bewertung
2 lesenswert
nicht lesenswert
... und wenn man nicht aus allem einen Glaubenskrieg und eine 
philosophische Dissertation machen muss, ist OOP einfach nur ein 
praktisches Werkzeug, das bei korrekter Anwendung die gewünschten 
Ergebnisse liefert.

Das Kreis-Ellipse-Problem basiert übrigens zu mindestens 90 % auf der 
übertrieben vereinfachten Vorstellung, dass Vererbung mit einer "ist 
ein"-Beziehung in natürlicher Sprache gleichzusetzen ist. Sobald man 
das verstanden hat, ist es kein "Problem" mehr, eher ein lehrreiches 
Beispiel, warum man sich bei der Modellierung weniger auf anschauliche 
Vorstellungen als auf die tatsächliche Schnittstelle, die eine Klasse 
definiert, konzentrieren sollte.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
Tim schrieb:
> Welches Buch/Tutorial mit praxisnahen Beispielen käme noch infrage?
> Geplante Anwendung --> umgesetzte Klassenstruktur

Eins vorweg:

Erst einmal solltest du dir dessen bewusst sein, dass Objektorientierung
in Python kein Dogma ist.

Python unterstützt neben der objektorientierten auch die prozedurale und
ein Bisschen die funktionale Programmierung. Guten Python-Code zeichnet
aus, dass er jedes der genannten Paradigmen dort und nur dort einsetzt,
wo es auch logisch sinnvoll ist.

Anders als bspw. in Java ist es in Python absolut verpönt, jedes noch so
kleine Detail in eine eigene Klasse zu wickeln, nur um irgendwelchen
OOP-Grundsätzen Genüge zu tun.

Es gibt viele guten Python-Programme, die ohne oder mit nur ganz wenigen
selbstgeschriebenen Klassen auskommen.

Andererseits ist es natürlich unklug, dort, wo die die OOP sinnvoll
einsetzbar ist, auf ihre Möglichkeiten und Vorteile zu verzichten.


Ich habe zwar noch nie ein Python-Buch gelesen, aber nach kurzem
Überfliegen erscheint mir das folgende ganz passend zu sein:

  "Python 3 Object-Oriented Programming" von Dusty Phillips

Du kannst ja auch mal einen Blick hineinschmeißen, um zu sehen, ob es
dir zusagt.


Zum Schluss noch ein kurzer Tipp, wie du für den Anfang ganz leicht
potentielle Objekte in deinem Programm finden kannst:

Wenn du das Programm logisch in mehrere Funktionen aufgeteilt hast und
dann feststellst, dass du häufig das Schlüsselwort "global" benutzen
musstest, oder dass mehrere der Funktionen gemeinsame Argumente haben,
ist das ein starkes Indiz dafür, dass die globalen Variablen (oder ein
Teil davon) bzw. die gemeinsam genutzten Funktionsargumente, jeweils
zusammen mit den Funktionen, die sie verwenden, ein Objekt bilden.

Das ist natürlich nur ein ganz kleiner Aspekt der OOP. Schwieriger wird
es u.a. bei der Frage nach einer optimalen Vererbungshierarchie bzw.
wann Vererbung überhaupt sinnvoll ist.

von Pandur S. (jetztnicht)


Bewertung
1 lesenswert
nicht lesenswert
Der Beginn liegt bei den Fundamenten der OOP. Dort wo Daten und Code 
zusammengehoeren, kann man die mit Klassen verbinden.
Das ist schon sehr effizient.
Vererbung kommt sehr viel speaeter, wenn in einem Projekt auffaellt, 
dass man aehnliche Klassen bildet.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
🐧 DPA 🐧 schrieb:
> Die Idee hinter OOP ist ja schön, es erscheint Intuitiv, Dinge zu
> Klassifizieren, und sich zu überlegen x ist ein y, y ist ein z, etc.
> Aber Ich denke es ist wichtig von Anfang an zu verstehen, das sich eben
> nicht alles sauber auf die Weise Abbilden lässt.
>
> In punkto Programmstrukturen baut OOP auf 3 Dinge auf:
>  1) Das Kapseln/Zusammenfassen zusammengehörender Daten (Objekte)
>  2) Das assoziieren auf diese anwendbarer Funktionen zu diesen
> (Methoden)
>  3) Erweitern bestehender Objekte, sowie das Überschreiben derer
> Methoden und Eigenschaften. (Vererbung)

Dr. Alan Kay, der die Objektorientierung und das Fachwort dafür erfunden 
hat, sagt dazu das Folgende: "OOP to me means only messaging, local 
retention and protection and hiding of state-process, and extreme 
late-binding of all things." [1]

Zusammengehörige Daten kann ich auch ohne OOP zusammenfassen, dazu 
bieten klassische Programmiersprachen wie C Strukturen (struct) und 
Pascal seine Records. Aber diese Sprachen bieten sprachseitig keine 
Möglichkeit, die Funktionen, die sie verarbeiten sollen, an ihre 
Datenstrukturen zu binden. Mit ein bisschen Gehacke kann man etwas 
Ähnliches auch in vielen nicht-OO-Sprachen wie C abbilden, aber nur sehr 
unelegant; IMHO gehören Deine ersten beiden Punkte jedenfalls direkt und 
sehr eng zusammen.

Die Vererbung ist eine andere Geschichte und eine Folge aus dem zuvor 
Gesagten, und für die Vererbung ist es teilweise richtig zu sagen, daß 
sie der Deduplizierung von Code dienen. Im Grunde dient die Vererbung 
aber zunächst dem Ziel, ähnliche Objekte zusammenzufassen und sie 
typsicher zu machen. In dem beliebten Auto-Beispiel heißt das, daß ich 
eine Klasse Fahrzeug mit einer abstrakten Methode beschleunige() habe, 
und davon dann meine Klassen Auto und Motorrad ableite. Wenn nun die 
Businessjungs sagen, "beschleunige das Ding", dann kann ich einfach die 
Methode beschleunige() autrufen, und zwar unabhängig davon, ob das 
betreffende Dingsi jetzt ein Auto oder ein Motorrad ist.

> Der Zweck von dem ganzen OOP zeug ist ja eigentlich, auf intuitivem Weg
> Code dublizierung zu vermeiden, und die Codequalität und Zuverlässigkeit
> des Programms zu erhöhen. Das kann man damit oft auch recht gut machen.

Der tiefere Sinn der OOP ist IMHO, den Code übersichtlicher zu 
organisieren und die Daten sowie die Funktionen, die sie bearbeiten, 
zusammenzufassen. Damit kann man auch die Duplizierung von Code 
vermeiden, aber das ist nicht das Ziel.

> Das blöde daran ist halt nur, wenn man nicht aufpasst und es übertreibt,
> kann man sich schnell in eine Ecke designen, und grobe Designprobleme
> sind dann oft viel schwieriger zu lösen, als ein paar flache Code Bugs /
> Fehlfunktionen.

Ich weiß, diese Kritik an der OOP ist nicht neu, und  war angesichts 
jener Zeit vor zwanzig Jahren, als "Objektorientierung" ein 
Verkaufsargument für manche Scharlatane war und es auch noch nicht so 
sehr viel Erfahrung mit dem Konzept gab, durchaus auch berechtigt. Aber 
es erscheint mir etwas widersinnig, jemandem ein neues Paradigma 
nahezubringen, indem man vor historischen (und teilweise hysterischen" 
Irrtümern warnt. Fakt ist: die saubere Strukturierung von Code und Daten 
ist eine Sache der Erfahrung, der Praxis, abstraktem Denkvermögen und 
der Fähigkeit, sein Problem vor und während der Umsetzung immer wieder 
aus der Vogelperspektive zu betrachten. Das gilt allerdings nicht nur 
für OOP, sondern auch für imperative, prozedurale, und funktionale 
Programmierung.

> Und nur um Code zusammenzufassen und übersichtlich zu
> halten, braucht man nicht unbedingt das ganze OOP und Vererbung.

Das ist ein bisschen... halbrichtig. Um die OOP sinn- und nutzbringend 
einsetzen zu können, muß man sie idealerweise komplett kennen. Richtig 
ist allerdings, daß man nicht in jedem OO-Programm alle Mittel und 
Möglichkeiten nutzen muß, die sie einem bietet. Ich persönlich schätze, 
daß etwa 70% meiner Python-Programme eigene Klassen nutzen, aber maximal 
5% meiner Python-Programme nutzen zB. die Vererbung. Es ist gut seinen 
ganzen Werkzeugkasten zu kennen, aber trotzdem nur den sinnvollen Teil 
davon zu benutzen -- nur weil ich einen Hammer darin habe, muß ich ihn 
nicht benutzen, um eine Schraube in die Wand zu bekommen.

[1] http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en

von Wühlhase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Tim schrieb:
> Danke für die bisherigen Kommentare.
> Welches Buch/Tutorial mit praxisnahen Beispielen käme noch infrage?
> Geplante Anwendung --> umgesetzte Klassenstruktur

Was ich dir empfehlen würde: Befasse dich mal mit Entwurfsmustern.

Die Programmierbeispiele sind zwar in Java, aber das Buch ist didaktisch 
großartig:
https://www.amazon.de/Entwurfsmuster-von-Kopf-bis-Fu%C3%9F/dp/3955619869/ref=sr_1_3?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=java+von+kopf+bis+fu%C3%9F&qid=1578822471&sr=8-3

Ich kenne Python nicht, aber wenn die Sprache halbwegs etwas taugt dann 
sollten die Beispiele daraus auch auf Python anwendbar sein.

von Wühlhase (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich denke, danach hast du eine recht brauchbare Vorstellung davon, 
welche Vorteile Klassen usw. bieten.
Auch über die klasischen Beispiele, die Gegenstände im Code nachbilden 
wollen, hinaus.

von Kalle Knöpfle (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Das hier liest du dir durch:
http://openbook.rheinwerk-verlag.de/oop/

Nicht zu lange aufhalten nur damit die mal nen Überblick bekommst,
dann gehst du an dein Projekt.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.