Das deutsche Python-Forum

? Wozu brauch man ~Klassen~ ?

ich habe bereits gemerkt, dass Klassen zu den unumgänglichen Sachen gehören, wenn man das Programmieren mit Python erlernen will.

Dennoch meine Frage:

Könnte man dies auch alles umgehen?

Vorausgesetzt die Lösung soll in Python erfolgen:

[ ] Will man das.

Natürlich kann man das umgehen, es gibt genug Sprachen, welche keine Klassen verwenden. Aber warum sollte man ohne auskommen wollen?

Klassen sind einfach nur eine Methode zu modellieren/abstrahieren. Klassen bieten sich oft an aber nicht immer.
Wenn es sich anbietet wuerde ich davon auf jeden Fall gebrauch machen.
Der Code wird besser (verständlicher, wartbarer) sofern der Softwaredesignansatz ordentlich dokumentiert ist.

Wie ist das eigentlich, wenn Frauen das Problem ohne Klassen lösen wollen?

Pascal hat geschrieben:ich habe bereits gemerkt, dass Klassen zu den unumgänglichen Sachen gehören, wenn man das Programmieren mit Python erlernen will.

Trifft so nicht zu. Inbesondere in der ersten Lernphase - falls Python die erste Programmiersprache ist, die man überhaupt kennenlernt - kommt man mit Klassen eigentlich nicht in Berührung (es sei denn, es ist ein spezieller Ansatz, der gerade diesen Weg geht, aber auf solche Ideen kommt man IMHO nur, wenn man zu lange mit Sprachen zu tun hatte, die einem Klassen aufzwingen).

Ich habe mir den Zugang zu Klassen / OOP mühselig als Autodidakt angeeignet (nachdem ich vorher einige Jahre zufrieden prozedural programmiert hatte) und habe lange Zeit nicht verstanden, wozu das gut sein soll. Das lag zum großen Teil daran, dass es eine Sprache war, die einem Klassen aufzwingt und ich einfach nicht verstehen konnte, warum man für ein kleines Programm mit ein paar Dutzend Zeilen einen Klassenentwurf braucht.

Die Antwort ist ganz einfach: Man braucht es eben in der Regel nicht für so eine kleine Sache. Den eigentlichen Nutzen entfaltet die OOP erst, wenn ein Projekt größer wird, speziell dann, wenn es nicht ein Ein-Mann-Projekt ist. Da man beim Einstieg in die Programmierung aber noch nicht in größeren Projektentwürfen denkt (denken kann), kann es zur Quälerei werden, sich für ein kleines Programm zu überlegen, wie man einen Klassenentwurf aufbaut und es objektorientiert umsetzt. Dadurch entstehen eher übertrieben aufgeblasene Quelltexte als sinnvoll strukturierte Programme.

Das führt dann auch dazu, dass die Beispiele in Lehrbüchern/Tutorials zur Einführung der OOP oft ziemlich gekünstelt sind. Soweit ich mich erinnere, gibt es zu diesem Thema auch einen längeren Thread im Forum, der von Leonidas mal angestoßen wurde.

Mann kann ALLE Probleme auch ohne Klassen lösen.

Weder noch, bzw. ist Dein ALLE irreführend, da es nicht berechenbare Probleme gibt, die also kein heutiger Rechner lösen kann.

Ansonsten gilt eine vermeintliche Turing-Vollständigkeit, hierfür brauchts keines Klassenkonstruktes.

Klar kann man alles ohne Klassen lösen aber rein prozedurales Programmieren ist (imho) hässlich und rein funktionales Programmieren ist in Python langsam.

Objektorientierung ist tief in der Sprache verwurzelt dass kann man nicht einfach ignorieren, will man idiomatisches Python schreiben. Es mag am Anfang etwas dauern aber wenn der Moment eintritt bei dem es "Klick" macht, wirst du merken wie einfach und elegant sich auf diese Weise komplexere Probleme lösen lassen.

Erstmal zwingt einen Python im Gegensatz zu Java nicht, mit Klassen zu programmieren. Wichtig.
Daß alles auch ohne Klassen geht, sieht man an C.

Dann: Ich sehe Klassen eher so wie Perl (d.h. das noch aktuelle Perl 5) sie sieht: Grundsätzlich als Pakete, Container (Perl: packages), in denen man bequem Variablen und Funktionen zusammenfassen und sie so von anderen Namensräumen abgrenzen kann.
Dann hat man so ein Zwischending zwischen globalen Variablen (die leicht unübersichtlich würden) und nur einzelnen Funktionen (denen man oft allzuviele Argumente übergeben müßte (anstrengend)).
Den Rest der OOP-Theorie verwende ich eigentlich weniger, bzw. habe ich selten eine Idee für ein wirkliches Objekt, bzw. für "Objektdesign".

@Pascal: Ich sehe, Du fragst auch in der Tkinter-Sektion: Schreib doch z.B. mal eine mittelgroßes Tkinter-GUI, ohne es in einer Klasse zu kapseln (wie das viele in Perl/Tk machen). Geht, aber ist doch ziemlich unbequem: Ist doch toll, wenn nach einem Klick Deine dadurch aufgerufene Methode auch das Entry-Feld kennt, auf das es dann Entry.get() anwenden kann.

Gruß

@numerix: Problembär hat's schon angesprochen: Bei GUI-Programmierung mit Tkinter kommt man kaum sinnvoll um eigene Klassen herum. Da hat man dann aber auch einen Punkt erreicht, wo die Klassen sinnvoll sind, und nicht nur "Spielzeugbeispiele".

Ansonsten habe ich mit Nein gestimmt, weil ich nicht mal davon ausgehe, das sich ALLE Probleme *überhaupt* lösen lassen, ob nun mit oder ohne Klassen. Oder hat jemand eine schöne Lösung für "Weltfrieden"?

Selbstverständlich kann man Gui-Programme
auch im Basic-Stil schreiben, wo das hinführt,
zeigt der Link in
http://www.python-forum.de/post-125376.html#125376
(Ein Danke an Jonas, der uns dieses abschreckende Beispiel erhalten hat)

So etwas will wohl aber wirklich niemand haben wollen.


yipyip

BlackJack hat geschrieben:@numerix: Problembär hat's schon angesprochen: Bei GUI-Programmierung mit Tkinter kommt man kaum sinnvoll um eigene Klassen herum.

Ja, keine Frage (jedenfalls, wenn es über Mini-Programme hinausgeht).

Vielleicht hätte ich oben gleich dazu schreiben sollen, dass Programmieranfänger IMHO eher nicht gleich mit GUI-Programmierung anfangen sollten, obwohl das gerade für viele der (oder ein wichtiger) Reiz zu sein scheint. Denn dann kommt ja genau das heraus, was man hier im Forum immer wieder zu sehen bekommt, nämlich grausamer Code, weil jemand sich an der GUI-Programmierung versucht, bevor er zumindest die Grundlagen der OOP in Python verstanden hat.

numerix hat geschrieben:

Pascal hat geschrieben:ich habe bereits gemerkt, dass Klassen zu den unumgänglichen Sachen gehören, wenn man das Programmieren mit Python erlernen will.

Trifft so nicht zu. Inbesondere in der ersten Lernphase - falls Python die erste Programmiersprache ist, die man überhaupt kennenlernt - kommt man mit Klassen eigentlich nicht in Berührung (es sei denn, es ist ein spezieller Ansatz, der gerade diesen Weg geht, aber auf solche Ideen kommt man IMHO nur, wenn man zu lange mit Sprachen zu tun hatte, die einem Klassen aufzwingen).

Aja, inwiefern kommt man bei so sachen wie oder nicht mit objektorientierter programmierung in Beruehrung? Python is objektorientiert und wird es immer bleiben, egal wie du damit herumwurschtelst. Und um das ordentlich zu verstehen sollte man sich auch mit Klassen beschaeftigen.

Eine ernst gemeinte Antwort:

(Ich meine, wie schwer ist es einem Thread einen sinnvollen Titel zu geben, wenn man schon umbedingt eine unnötige Umfrage haben muss)

Ok, zwar ein Doppelpost...

Wie meine Vorposter gemeint haben kann man natürlich alles ohne Klassen lösen. Schau dir den Assembler-Output von g++ an, dort entdeckst du keine einzige Klasse obwohl man in C++ Klassen nutzt.

Die Idee ist aber, die richtigen Abstraktionen zu nutzen. In Python nutzt man oft Funktionen und es ist die richtige Abstraktion wenn das Problem gut durch Funktionen gelöst werden kann. Wenn man aber Dinge darstellen will, weil eine einfache Funktionsabstraktion nicht reicht, da die Dinge auch noch einen internen Zustand haben, sind Klasse oft nützlich. Aber man sollte es natürlich nicht übertreiben, denn Klassen sind ebenso wie Funktionen nur ein Mittel zum Zweck und sollen die Übersichtlichkeit des Codes erhöhen (für Menschen! Dem Computer ist das völlig egal), daher sollte man sich die Mühe machen die richtige Abstraktion zu verwenden. Das erfordert zwar etwas Übung aber danach bekommt man ein Gefühl wann es sinnvoll ist, Klassen zu verwenden und wann nicht.

In Python ist OOP recht integraler Bestandteil der Sprache und man sollte damit umgehen können, bevor man sich an größere Projekte wagt, die über das übliche Wegwerfskript hinausgehen. Wenn das Projekt keine Klassen erfordert, muss man sie nicht einsetzen, aber wenn der Einsatz von Klassen das Programm simpler macht, dann ist es gut zu wissen dass man Klassen bauen kann, statt irgendwas prozedural zusammenzustecken.

Ich bin persönlich kein sonderlich großer Freund von OOP sondern versuche es realistisch zu sehen; wenn ein funktionaler Ansatz sinn macht und elegant ist - warum nicht. Wenn es aber zu starken Verrenkungen führt und Klassen das Problem besser beschreiben - dann auf jeden Fall OOP.

Leonidas hat geschrieben:(Ich meine, wie schwer ist es einem Thread einen sinnvollen Titel zu geben, wenn man schon umbedingt eine unnötige Umfrage haben muss)

Deswegen habe ich diese Frage bei Just Testing reingeschrieben, weil dies denn nach einer Woche gelöscht werden sollte..

Aber ich bin von den bisherigen Antworten positiv überrascht!!!

Vielen Dank dafür

Pascal hat geschrieben:Deswegen habe ich diese Frage bei Just Testing reingeschrieben, weil dies denn nach einer Woche gelöscht werden sollte..

Just Testing ist nicht für Diskussionen oder Fragen gedacht.

FAZIT:
Das "verallgemeinerte-Übersichtlichkeits-Problem" lässt sich ohne Klassen NICHT lösen . Es ist ja auch ein sehr komplexes Problem.

Goswin hat geschrieben:Das "verallgemeinerte-Übersichtlichkeits-Problem" lässt sich ohne Klassen NICHT lösen .

Logisch geht das, nur ist es nunmal so dass man in Python für so etwas meist Klassen einsetzt.
Sonst würdest du ja sagen, dass man in Programmiersprachen die keine Klassen haben, keine übersichtlichen Programme schreiben kann. Das stimmt aber so nicht.

@Goswin

Das kannst du so allgemein nicht sagen (und was ist eine allgemeine Übersichtlichkeit? ). Klassen sind ein Werkzeug, genau wie Generatoren / Koroutinen, Closures, Continuations, goto, Rekursion und nicht zuletzt auch Funktionen. Je nach Problem können mehrere Werkzeuge mehr oder weniger geeignet sein, manche hingegen absolut nicht. Man kann auch jedes beliebige iterative gelöste Problem auch rekursiv lösen. Das sagt aber nichts über die Qualität der Lösung aus. Manche Dinge lassen sich iterativ natürlicher lösen, andere Dinge dagegen rekursiv, wo einem die Lösung direkt ins Auge springt. Letztendlich gehört immer Abwägung dazu, denn man kann irgendwo alles als Objekt betrachten, das macht OOP auch gefährlich. Typischer Fall von "If you only have a hammer, everything looks like a nail.". Außerdem kann man Klassen mit Funktionen und Closures nachbilden, sofern die verwendete Sprache Funktionsdefinitionen innerhalb von Funktionen erlaubt.