in diesem Thread stelle ich keine Frage sondern ein Thema zur Diskussion - was ist OOP?
Für mich ist OOP nicht nur die Sprache. Die Sprache, in unseren Fall Python bietet syntaktischen Zucker und einige angenehme Erleichterungen. Jedoch ist nicht jedes Programm welches Klassen etc. nutzt in meinen Augen objektorientiert. Um das zu veranschaulichen führe ich einen weiteren Begriff ein, objektnutzend. Objektnutzend ist ein Programm, welches Klassen und Instanzen nutzt (im Sinne von selbst definiert, nicht im sinne dass es Built-in Datentypen verwendet). Solch ein Programm zu schreiben ist recht trivial, denn man kann ganz normale Prozedurale Programme in Objektnutzende Programme umwandeln indem man einfach alle Funktionen in Klassen packt. Dadurch werden die Klassen zu ihrer Art Namensräumen, aber das Programm an sich nicht Objektorientiert. Man kann es auch in die andere Richtung drehen indem man Objektorientierte Programme schreibt in einer Programmiersprache die dafür keine zusätzliche Syntax bietet. Diesen Weg haben etwa die GTK+-Entwickler genommen.
Objektorientierung besteht nämlich aus zwei Worten: Objekt (diese werden in Objektnutzenden Programmen verwendet) und Orientierung. Letzteres ist kein sprachlicher Aspekt sondern ein gedanklicher. Er beschreibt, dass sich der Autor Gedanken darüber gemacht hat, die Dinge die er schreibt zu abstrahieren. D.h. eine Klasse macht genau das, was sie machen soll und kümmert sich um nichts anderes.
Nehmen wir mal ein eine Abwandlung eines Codes ich heute gesehen habe. Ein klassisches Beispiel ist die Klasse `Shape` mit ihren Kindklassen `Circle`, `Rectangle` und `Triangle`. Jede dieser Klassen hat ein `draw()` - ganz logisch, Formen sollen sich zeichnen können. Das ist OOP. Nun fügt der Autor der Klasse noch ein `react_on_network_interrupt()` hinzu, weil es dort gerade passt. Damit ist es in meinen Augen eigentlich kein Objektorientierter Entwurf mehr da `react_on_internet_interrupt()` teil der Programmlogik ist und nicht der Objektlogik (das setzt natürlich vorraus, das `react_on_network_interrupt` nicht tatsächlich sinnvoll ist, etwa das Objekt grün färbt, wenn Daten über das Netzwerk kommen). Wenn aber `react_on_network_interrupt` etwa da ist, das Programm zu beenden dann hat es im Objekt nichts verloren - dann gehört es raus.
Das ist nun vergleichsweise schwer zu erklären, denn es ist eben eine Gedankliche Sache, keine die wenn man es falsch macht Exceptions wirft. Es geht eben darum, dass man Instanzen als Daten eines Programmes verwendet und nicht als Funktionen die den Programmfluss bestimmen. Das ist nicht ganz einfach zu verstehen und Programmiersprachen wie Java führen meiner Meinung nach dazu, dass Objektorientiertes Design vernachlässigt wird - alles muss Klassen sein, also kann man Klassen dazu einspannen prozedural zu Programmieren.
Insgesamt ist Objektorientierte Programmierung ähnlich weit von Prozeduraler Programmierung entfernt wie Funktionale Programmierung nur gibt Objektnutzende Programmierung einem den Anschein, dass man die Konzepte von OOP verstanden hat - es funktioniert doch alles. Dies ist aber manchmal ein Trugschluss, da man dann manchmal solche Objekte konstruiert, dass sie einem mehr im Weg stehen als dass sie einem Helfem. Daher bin ich auch kein Fan des Übertragens von Prozeduralen Programmen nach "OOP", weil nicht alle prozeduralen Probleme Objektorientiert einfacher werden. Objektorientierung ist ein Werkzeug, kein Zwang. Wenn etwas Objektorientiert keinen Sinn ergibt, dann muss man das Problem da auch nicht reinzwingen.
OOP zu kennen ist jedoch eine gute Sache, auch wenn man es nicht unbedingt einsetzen muss - das ist wiederrum ähnlich wie grundlegende funktionale Konzepte zu kennen. Dieses Wissen bringt einem auf den ersten Blick nicht viel, aber langfristig kann es einem Helfen ein besserer Programmierer zu werden, indem man weiß, wie man an ein Problem rangehen kann.
Manchmal ist es aber auch sinnvoll oder notwendig Klassen zu schreiben die nicht Objektorientierten Design genügen, nur heißt das nicht dass das Programm dadurch OOP ist.
Das ist meiner Meinung nach das was in vielen Büchern zu kurz kommt und es ist auch verständlich, denn dass ist eben die Theorie und viele Bücher wollen Praxis vermitteln. Es ist auch gar nicht so einfach zu vermitteln, denn das Gefühl was OOP ist und was nicht kommt vermutlich auch erst nach einiger Praxis. Wobei, da warne ich gleich davor, man kann nicht immer genau sagen "Das ist OOP, weil..." und "Das ist kein OOP, weil...". Die Übergänge sind fließend und es kann auch sein dass eine Mischung von beiden an einer gegebenen Stelle optimal ist.
Das wären meine Gedanken zu OOP, würde mich freuen wenn noch jemand was zu ergänzen hätte oder seine Meinung darstellen will. Beispiele wären aber auch super
