Das deutsche Python-Forum

Hallo,

Nachdem ich gerade in die 4. Auflage von Michael Weigands "Objektorientierte Programmierung in Python" reingeschaut habe und dort als Erstes etwas von __foo und stark privat (im Gegensatz zu _foo und schwach privat...) gelesen habe, habe ich das Ding direkt wieder aus der Hand gelegt und mir gedacht, dass hier doch bestimmt einige sind, die das Wesentliche der objektorientierten Programmierung in Python verstanden haben und das im [wiki=Objekte]Wiki [/wiki]auch so äußern können. Den bisherigen Text dort finde ich reichlich nichtssagend, daher würde ich vorschlagen, ganz neu anzufangen.

Sprechen wir anstatt von Objekten lieber von Klassen (Objekte sind Instanzen von Klassen). Das Konzept der Objektorientierung geht darum, welche Klassen man definiert.
Klassen wiederum erlauben es, die Realität zu modellieren. Du kannst dir bspw. die Welt anschauen und denken: "Hm, es gibt so Menschen und es gibt so Tiere und beide haben so Stoffwechsel und evtl. Beine oder Hirn, etc.". Und dann kannst du dir denken: "Ok, ich mach mal eine Klasse 'Säugetier'". Dadurch hast du die Realität auf ein Programm abstrahiert. Die Implementierung ist dann wieder dir überlassen. Diese Art von Beispiele sind sehr anschaulich. Aber es ist immer dir überlassen, in welchem Kontext du deine Modellierung vornimmts und dann wird plötzlich ein Vektorfeld eine Klasse.

mzh hat geschrieben:Sprechen wir anstatt von Objekten lieber von Klassen (Objekte sind Instanzen von Klassen). Das Konzept der Objektorientierung geht darum, welche Klassen man definiert.

Hui... da freue ich mich schon auf Reaktionen von Leonidas, sma, BlackJack und co

mzh hat geschrieben:Das Konzept der Objektorientierung geht darum, welche Klassen man definiert.

Dann müsste es ja Klassenorientierung heissen.

hendrikS hat geschrieben:
mzh hat geschrieben:Das Konzept der Objektorientierung geht darum, welche Klassen man definiert.
Dann müsste es ja Klassenorientierung heissen.

Naja, es gibt ja "class orientated" - aber eben als Unterkategorie von Objektorientierten Programmiersprachen, wenn man denn eine Taxonomie vornehmen mag. Aber wie gesagt... ich freue mich auf da auf Kommentare einiger Leute

@mzh: Zwei Kritikpunkte: Einmal die schon angesprochenen Klassen -- die sind in vielen OOP-Sprachen ein Mittel um Objekte zu beschreiben, aber sie sind nicht *notwendig* für Objektorientierung. Io zum Beispiel ist eine durch und durch objektorientierte Sprache und kennt nur Objekte und keine Klassen.

Und das andere ist die "Realität". Wird gerne in Beispielen für Anfänger gebracht, ist aber IMHO Unsinn. Nicht wenige von den "Säugetier"- oder "Fahrzeug"-Beispielen werden sogar recht schnell ziemlich realitätsfern.

Ich bin kein Spezialist...
Ich habe in meinem Post versucht, den nur durch den ersten Beitrag vermutbaren Kenntnisstand des Themenstarters zu antizipieren.
Ich denke, das wesentliche in diesem Thread sollte sein, Objektorientierung zu erklären. Gerne nehme ich konstruktive Kritik an meinem Post auf, aber der Threadstarter würde gerne wissen, was Objektorientierung bedeutet, da finde ich Klassen beim besten Willen nicht ganz unnützlich.

mzh hat geschrieben:Gerne nehme ich konstruktive Kritik an meinem Post auf, aber der Threadstarter würde gerne wissen, was Objektorientierung bedeutet, da finde ich Klassen beim besten Willen nicht ganz unnützlich.

Ich glaube da hast du ihn "etwas" falsch verstanden.

mzh hat geschrieben:Gerne nehme ich konstruktive Kritik an meinem Post auf, aber der Threadstarter würde gerne wissen, was Objektorientierung bedeutet, da finde ich Klassen beim besten Willen nicht ganz unnützlich.

Ja, aber es geht auch ohne, siehe Self oder Javascript.

mzh hat geschrieben:Sprechen wir anstatt von Objekten lieber von Klassen (Objekte sind Instanzen von Klassen).

Und Klassen sind.. keine Objekte? Also das letzte Mal wo ich nachgeschaut hab waren Klassen immer noch Objekte, nämlich "Instanzen" der Klasse ``type``.

Ich finde den Ansatz Objekte bei der Erklärung von Objektorientierung zu ignorieren, naja, etwas eigenwillig.

Zudem denke ich dass der Threadstarter durchaus weiß wie Python-OOP funktioniert nur eben auf den Mißstand in der Literatur hinweisen will.

BlackJack hat geschrieben:Und das andere ist die "Realität". Wird gerne in Beispielen für Anfänger gebracht, ist aber IMHO Unsinn. Nicht wenige von den "Säugetier"- oder "Fahrzeug"-Beispielen werden sogar recht schnell ziemlich realitätsfern.

Ja, da gibt es dann die typische Mehrfachvererbung von "Boot" und "Auto" und hat plötzlich ein Fahrzeug das schwimmen und fahren kann

Leonidas hat geschrieben:Zudem denke ich dass der Threadstarter durchaus weiß wie Python-OOP funktioniert nur eben auf den Mißstand in der Literatur hinweisen will.

Ja, das sehe ich auch so. Die Diskussion geht in die völlig falsche Richtung.

Noch etwas allgemeines zum Thema Python-Bücher:
Ich habe schon lange im Hinterkopf, eine Art Blacklist mit Pythonbücher zusammenzustellen, die eigentlich den Python-Paradigmen widersprechen und deshalb zum Pythonlernen nicht empfehlenswert sind.

ice2k3 hat geschrieben:Ja, da gibt es dann die typische Mehrfachvererbung von "Boot" und "Auto" und hat plötzlich ein Fahrzeug das schwimmen und fahren kann

Dann erbt man von Fahrzeug und AutoMixin sowie BootMixin

Für jedes Problem welches OOP bietet gibt es ein Pattern mit dem man es tot schlägt

P.S.:Java ist natürlich Leichenschändung.

ice2k3 hat geschrieben:Noch etwas allgemeines zum Thema Python-Bücher:
Ich habe schon lange im Hinterkopf, eine Art Blacklist mit Pythonbücher zusammenzustellen, die eigentlich den Python-Paradigmen widersprechen und deshalb zum Pythonlernen nicht empfehlenswert sind.

Da sehe ich allerdings die Gefahr, dass der Maßstab so hoch gehängt wird, dass am Ende wenig mehr als nichts übrig bleibt. Über das vom OP genannte Buch von Michael Weigend (allerdings nicht die 4. Auflage) habe ich mich im Forum auch schon gelegentlich geäußert und aus meiner Sicht ist es nicht das Schlechteste, wenn man gerne etwas deutschsprachig-Gedrucktes haben möchte.

Ach, da fällt mir ein: Wollte Leonidas nicht mal ein Python-Buch schreiben ...

numerix hat geschrieben:Ach, da fällt mir ein: Wollte Leonidas nicht mal ein Python-Buch schreiben ...

Sollte dass nicht nur ein Tutorial über OOP werden?

ice2k3 hat geschrieben:Ja, da gibt es dann die typische Mehrfachvererbung von "Boot" und "Auto" und hat plötzlich ein Fahrzeug das schwimmen und fahren kann

Wieso gibt es doch?

Code: Alles auswählen

class Amphibienfahrzeug(Auto, Boot):
    pass

Hyperion hat geschrieben:Hui... da freue ich mich schon auf Reaktionen von Leonidas, sma, BlackJack und co :-D

Ich zitiere mich mal selbst: http://www.python-forum.de/post-161629.html#161629 ;)

Übrigens, Self (von dieser Sprache wurden dann Sprachen wie NewtonScript, JavaScript, Io oder Ioke beeinflusst) war nicht die erste Sprache mit prototypischer Vererbung. Self stammt von 1987, wenn ich nicht irre. Auf der ersten OOPSLA 1986 (5 Jahre nach Smalltalk-80) haben LaLonde, Pugh und Dave Thomas (nicht der von den Pragmatic Programmers sondern der Gründer von OTI) ein "exemplar based Smalltalk" vorgestellt und Lieberman hat ebenfalls etwas zu diesem Thema gemacht und bestimmt haben auch andere in den 5 Jahren, in denen es Smalltalk gab, derartige Ideen ausprobiert. Letztlich kommt das alles von Hewitts Actor-Idee, die er 1973 veröffentlicht hat und die Steele und Sussman inspiriert hat, Scheme zu entwerfen.

Übrigens^2: Vererbung war ursprünglich bei Smalltalk als Implementationsdetail zur Codeersparnis gedacht gewesen und bei weitem nicht als Mittel, Typ- bzw. Klassenhierarchien aufzubauen, wie es zu gerne als erstes motivierendes Beispiel für OOP in vielen Büchern genannt wird. Ich glaube, es war Lisp, das erkannt, dass man den "typecase"-Mechanismus ja ausbauen und zum Dispatch von Multimethoden nutzen könnte, woraus dann, übertragen auf statisch getypte Sprachen dann der Irrglaube entstand Typhierarchie == Klassenhierarchie. Man muss Java hoch anrechnen, dass sie durch Interface-Typen versucht haben, diesen frühen Fehler vieler Programmiersprachen zu korrigieren.

Stefan

numerix hat geschrieben:
ice2k3 hat geschrieben:Noch etwas allgemeines zum Thema Python-Bücher:
Ich habe schon lange im Hinterkopf, eine Art Blacklist mit Pythonbücher zusammenzustellen, die eigentlich den Python-Paradigmen widersprechen und deshalb zum Pythonlernen nicht empfehlenswert sind.
Da sehe ich allerdings die Gefahr, dass der Maßstab so hoch gehängt wird, dass am Ende wenig mehr als nichts übrig bleibt. Über das vom OP genannte Buch von Michael Weigend (allerdings nicht die 4. Auflage) habe ich mich im Forum auch schon gelegentlich geäußert und aus meiner Sicht ist es nicht das Schlechteste, wenn man gerne etwas deutschsprachig-Gedrucktes haben möchte.

Man muss das ganze ja auch nicht als Blacklist oder nicht empfehlenswert auflisten und kann alle Bücher mit einer kurzen Rezession versehen. (Selbstverständlich werden dann auch gute Bücher aufgenommen).

Ich glaube schon, dass ich OO halbwegs verstanden habe.

Etwas anderes ist es jedoch, das präzise so in Worte zu fassen, dass es auch andere verstehen. Ich hatte gehofft, in dem Buch von Weigend, das ja schonmal lobend erwähnt wurde, etwas in der Richtung zu finden. Leider anscheinend Fehlanzeige... Auch den Text im Python-Wiki fand ich höchstens hilfreich für Leute, die bereits OO verstanden haben, jedoch aus einem anderen Sprachkontext (Java?) kommen.

Es gibt ein Buch vom Verlag Galileo Computing, das sich mit dem Thema OOP beschäftigt und dabei nicht auf eine Sprache spezialisiert ist: Objektorientierte Programmierung — Das umfassende Handbuch (von Bernhard Lahres und Gregor Rayman). Ich habe es selber nicht gelesen, kann es also auch nicht bewerten. Aber vielleicht kennt es hier jemand und kann etwas dazu sagen. Es ist übrigens auch ein OpenBook; wer will, kann es daher auch mal "überfliegen", um seinen ersten Eindruck zu vermitteln.

mkesper hat geschrieben:Auch den Text im Python-Wiki fand ich höchstens hilfreich für Leute, die bereits OO verstanden haben, jedoch aus einem anderen Sprachkontext (Java?) kommen.

Java ist mehr an Klassen als an Objekten orientiert.