OOP vs. Nicht OOP

[ines]

@all

Ich fange gerade mit Python an ...
Früher C danach C++.

Bei der Lösung eines Problems kann ich klassisch ohne OOP (Objektorientierte Programmierung) vorgehen
oder auch mit OOP.

Anmerkung, ich gestalte gerade ein Haushaltsbuch.
Die Umsätze werden in Konten erfasst (Aufwendungen, Erträge, Bank, ...) und über andere Konten abgeschlossen.

Frage an die comm:
Wie sind eure Erfahrungen hinsichtlich OOP oder kein OOP?
Prozessor, Speicher, Geschwindigkeit, etc.

Viel Spaß beim Diskutieren, Philosophieren, ...

/ines

[BlackJack]

@ines: Prozessor, Speicher, und Geschwindigkeit sind schon mal egal. Wenn man sich um so etwas ohne eine konkrete Implementierung, die zu langsam ist, Gedanken macht, dann ist man bei Python bei der falschen Sprache. Es kommt auf Les- und Wartbarkeit an.

Und da kommt man im Grunde bei den meisten nicht-trivialen Sachen nicht um etwas OOP herum, denn sonst kann man keine komplexeren Datenstrukturen aufbauen. Die Grunddatentypen wie Listen und Dictionaries zu verschachteln wird syntaktisch unangenehm und/oder sehr schnell unübersichtlich.

Ansonsten kann man OOP und funktional in Python ganz nett mischen.

[problembär]

Das Schöne ist, daß Python beides problemlos zuläßt.

Aber insbesondere wenn man ein GUI schreibt, wäre Nicht-OOP schon sehr ungebräuchlich und auch wirklich umständlich.

Obwohl ich also eigentlich kein großer Freund von OOP bin, schreibe ich dennoch meistens so, weil ich meistens wenigstens eine kleine Tkinter-Oberfläche haben möchte.

Gruß

[ines]

Danke.

Progrämmchen lief bisher ohne GUI oder MiniGUI ...
Wie vor 20 Jahren ...

Wie gesagt,
danke.

/ines

[Darii]

Progrämmchen lief bisher ohne GUI oder MiniGUI ...
Wie vor 20 Jahren ...

Da gabs auch schon lange GUI(die gibts seit ca. 40 Jahren und auf dem Massenmarkt seit ca. 30), Text-only ist also schon sehr 1960

Zu deiner Frage: Zumindest die Verwendung von Klassen als Datenstruktur bietet sich bei Python an und dann kann man auch gleich Methoden schreiben…

[mutetella]

In der Welt des Programmierens bin ich vom Säugling gerade mal ins Kleinkindalter entwachsen, kann deshalb nicht wirklich etwas zu "OOP vs. Nicht OOP" sagen.
Allerdings musste ich heute morgen daran denken, dass einer der ersten Aussagen, die ich gelesen hatte, als ich mich mit der Programmiermaterie zu beschäftigen begann die war, dass ein Programm ein Abbild der Wirklichkeit ist. Und die Wirklichkeit, wie wir sie kennen, besteht im weitesten Sinne aus Objekten.
Wenn ich mir z. B. überlege, was es heute mittag zu Essen geben könnte, dann ist ja bereits die Überlegung ein Objekt. Und bis letztlich das Schnitzel mit Pommes und einem Salat auf dem Tisch stehen, wurden noch einige weitere Objekte erstellt.
Wenn ich mir also überlege, wie ich ein Programm gestalte, so finde ich den Ansatz der OOP (Welche Objekte habe ich bereits? Welche Objekte benötige ich? ...) dabei hilfreicher als mir Gedanken darüber machen zu müssen, welche einzelnen Arbeitsschritte nötig sind, um ein bestimmtes Ergebnis zu erhalten.

Gruß
mutetella

[ines]

Vor 20 Jahren hatte ich i386 mit Win 3.0 und MS-DOS 4.01 ...
Meine Progrämmchen waren ganz bestimmt nicht auf eine GUI angewiesen.

Ohne unhöflich zu sein möchte ich das Thema "GUI & ich" an dieser Stelle beenden.
Selbstverständlich könnt ihr weiter diskutieren, philosophieren, in Erinnerungen schwelgen ...

Beste Grüße aus Jena,
wahre Landeshauptstadt von Thüringen ;-)

[mutetella]

Progrämmchen lief bisher ohne GUI oder MiniGUI ...

Aber ganz ohne UI wird Dein Haushaltsbuch nicht auskommen, oder? Selbst wenn Dein UI 'nur' textbasiert arbeitet, so kann Dir die objektorientierte Herangehensweise dabei sehr hilfreich sein.
Ganz tief unten ist und liefert eine Texteingabe

Code: Alles auswählen

betrag = raw_input('Bitte Betrag in EUR eingeben: ')

auch nichts anderes als ein Objekt.
Genau wie es das entsprechende Pendant in wx, GTK, Qt ... auch ist und macht.

Gruß
mutetella

[snafu]

Allerdings musste ich heute morgen daran denken, dass einer der ersten Aussagen, die ich gelesen hatte, als ich mich mit der Programmiermaterie zu beschäftigen begann die war, dass ein Programm ein Abbild der Wirklichkeit ist.

Hast du diese These seitdem kritiklos übernommen oder sie auch mal hinterfragt? Ich mein, was haben denn irgendwelche Video-Codecs, SQL-Abfragen, Webseiten-Programmierung u.v.m. mit der Wirklichkeit zu tun? Inwiefern sollen die jetzt Abbilder davon sein? Selbst wenn man von der "Backend-Ebene" weggehen würde und nur Programme nimmt, die direkt mit dem Anwender interagieren, dann sehe ich da nirgendwo Abbilder von der Wirklichkeit. Was soll dieser Begriff denn eigentlich genau bedeuten, insbesondere im Zusammenhang mit OOP?

Eine Klasse in der Programmierung ist ganz einfach etwas erdachtes abstraktes, damit man Dinge besser benutzen kann, weil es eben ins menschliche Denken passt. Sei es zur Darstellung einer Struktur, wie ja schon von BJ angesprochen wurde oder ganz pragmatisch, weil man merkt, dass man besonders oft das selbe Argument bei seinen Funktionen erwartet (z.B. ein gtk_window) und durch OOP quasi gewissen Overhead loswerden möchte. Auch kann man dank OOP recht anschaulich mit gewissen Zustandsveränderungen arbeiten. Bei all diesen Dingen sollen aber in meinen Augen keine Abbilder von der Wirklichkeit dargestellt werden. Auch die Tatsache, dass in Python alles ein Objekt ist, heißt noch lange nicht, dass Python Abbilder von der Wirklichkeit (in einer wie auch immer gearteten Form) zugänglich machen möchte.

Wenn ich mir also überlege, wie ich ein Programm gestalte, so finde ich den Ansatz der OOP (Welche Objekte habe ich bereits? Welche Objekte benötige ich? ...) dabei hilfreicher als mir Gedanken darüber machen zu müssen, welche einzelnen Arbeitsschritte nötig sind, um ein bestimmtes Ergebnis zu erhalten.

Hier scheinst du das Design einer Schnittstelle mit seiner konkreten Implementierung zu verwechseln/vermischen. Natürlich kannst du dein API gern in objektorientierter Form gestalten. Trotz alledem müssen doch konkrete Funktionen (selbst wenn sie als Methoden daherkommen) erstellt werden. Wenn du weißt, dass du "gefrorenes Schnitzel", "Butter", "Herd" und "Bratpfanne" hast, braucht es am Ende trotzdem die Funktion des Bratens, um etwas vom Typ "essbar" zu erhalten.

[mutetella]

... die direkt mit dem Anwender interagieren, dann sehe ich da nirgendwo Abbilder von der Wirklichkeit.

Ist nicht die Interaktion schon ein Abbild der Wirklichkeit?

Code: Alles auswählen

essen = ['Schnitzel', 'Pizza', 'Suppe']
print 'Schatz, was willst Du heute essen?'
auswahl = raw_input('{0}, {1} oder {2}?'.format(*essen))

Was soll dieser Begriff denn eigentlich genau bedeuten, insbesondere im Zusammenhang mit OOP?

Hat nicht die Mehrzahl der Programme letztlich die Aufgabe, unsere Wirklichkeit abzubilden? Ob das eine Vereinsverwaltung, die Firmware meines MP3-Players, Need for Speed oder amazon.de ist. Diese und andere Programme verwalten Objekte aus meinem Leben oder schaffen Objekte, die ich in meinem Leben nutze.
Wenn sich nun ein Programmierer Gedanken über das Innen- wie auch das Außenleben seines Programmes macht, dann wird er doch dabei stets auch versuchen, einen Teil der Wirklichkeit abzubilden.
Das beginnt doch bereits bei der Überlegung, welche Bezeichnungen wir unseren Variablen, Klassen, Methoden etc. geben.

Eine Klasse in der Programmierung ist ganz einfach etwas erdachtes abstraktes, damit man Dinge besser benutzen kann, weil es eben ins menschliche Denken passt.

Und ist menschliches Denken und Handeln nicht die Wirklichkeit, die mit einer Klasse abgebildet wird?

Auch die Tatsache, dass in Python alles ein Objekt ist, heißt noch lange nicht, dass Python Abbilder von der Wirklichkeit (in einer wie auch immer gearteten Form) zugänglich machen möchte.

Welche Motivation hinter der Entwicklung objektorientierter Programmiersprachen stand, kann ich nicht beurteilen. Aber ich denke, dass irgendwann der Punkt erreicht war, an dem allein mit funktionaler Programmierung unsere objektorientierte Wirklichkeit nicht mehr darzustellen war.

Trotz alledem müssen doch konkrete Funktionen (selbst wenn sie als Methoden daherkommen) erstellt werden.

Natürlich. Das Gegenteil habe ich ja nie behauptet.

Gruß
mutetella

[snafu]

... die direkt mit dem Anwender interagieren, dann sehe ich da nirgendwo Abbilder von der Wirklichkeit.

Ist nicht die Interaktion schon ein Abbild der Wirklichkeit?

Nein, für mich nicht. Das ist eine *Schnittstelle* zur Wirklichkeit, also von der Welt der Daten in die Welt des menschlichen Denkens bzw zu den Abläufen, die außerhalb des Computers stattfinden (du hattest ja schon ein paar passende Beispiele genannt). Ein *Abbild* wäre für mich die Simulation eines Sonnenaufgangs oder sowas, also die möglichst genaue Wiedergabe eines real (d.h. außerhalb des Programms) stattfindenden Ablaufs. Ich finde den Begriff halt einfach unpassend gewählt. Ist aber dann auch wieder nichts, was für mich jetzt in seitenlangen Diskussionen ausarten muss.

[EyDu]

Auch die Tatsache, dass in Python alles ein Objekt ist, heißt noch lange nicht, dass Python Abbilder von der Wirklichkeit (in einer wie auch immer gearteten Form) zugänglich machen möchte.

Welche Motivation hinter der Entwicklung objektorientierter Programmiersprachen stand, kann ich nicht beurteilen. Aber ich denke, dass irgendwann der Punkt erreicht war, an dem allein mit funktionaler Programmierung unsere objektorientierte Wirklichkeit nicht mehr darzustellen war.

Du meinst sicherlich imperative Programmierung.

[BlackJack]

@mutetella: Du hast IMHO komische Definitionen von "Wirklichkeit" und (realen) Objekten. Die Überlegung was ich essen möchte, ist für mich kein Objekt -- das ist ein Gedanke.

Ich würde auch ganz schnell von dem "Abbild" weg zu kommen versuchen, denn Programme sind keine Abbilder sondern höchstens Abstraktionen einer Wirklichkeit. Und das alles baut im Rechner auf Zahlen auf -- unwirklicher geht es ja kaum. Zahlen sind in Python Objekte -- welche realen Objekte werden denn damit abgebildet? Zahlen in der "Realität" sind ja auch nur abstrakte Gedankenkonstrukte, die es nicht wirklich gibt, sondern nur in unseren Köpfen.

Ausserdem ist es gewagt zu behaupten, dass unsere Wirklichkeit eine objektorientierte Welt ist, denn letztendlich ist funktional genau so mächtig wie objektorientiert -- man kann also mit den beiden verschiedenen Abstraktionen, Lösungen für die gleichen Probleme formulieren. Und es ist beileibe nicht so, dass eines "natürlicher" als das andere wäre, denn ich kenne auch genug Leute, die mit funktionaler Programmierung auf Anhieb klar gekommen sind, mit OOP aber ihre Schwierigkeiten hatten. Das kommt ganz auf die Personen an und wie die "ticken", was ihnen mehr liegt und logischer, einfacher, leichter, … erscheint.

[mutetella]

Die Überlegung was ich essen möchte, ist für mich kein Objekt -- das ist ein Gedanke.

Solange die Frage in meinem Kopf ist, nennen wir es Gedanke. Formuliere ich Anweisungen, die diese Frage auf den Bildschirm schreiben, wird daraus ein Objekt. Das ist im Kern das, was ich ausdrücken möchte: Dass mir bei der Überlegung, wie ich ein bestimmtes Problem löse, objektorientiertes Denken sehr hilfreich erscheint.
Und dabei bleibt es natürlich nicht aus, dass ich zu lösende Probleme und Arbeitsabläufe, die mein Programm lösen und übernehmen soll, in Objekte stecke und somit diese Teile aus der Wirklichkeit in meinem Programm abbilde.

Aber ich glaube, dass die Diskussion hier viel zu sehr auf Begrifflichkeiten fixiert ist. Natürlich verstehen wir unter Objekten in der Realität etwas greifbares, fühlbares... Trotzdem finde ich die Beschreibung, dass Programme die/eine Wirklichkeit abbilden nach wie vor treffend. Denn letztlich machen wir doch sehr oft nichts anderes: Wir transportieren real existierende Arbeitsabläufe oder was auch immer in ein Programm.

Und eine Wertung funktional, imperativ, objektorientiert oder Schreibmaschine kann ich überhaupt nicht vornehmen. Dazu fühle ich mich einfach zu schwach auf der Brust...

Gruß
mutetella