Was ist OOP eigentlich?

Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Ich finde es schlau, zur Definition eines Begriffs den Erfinder des Begriffs zu Wort kommen zu lassen. Alan Kay hat Anfang der 70er Jahre das Wort "Objektorientierung" erfunden und damit eine ganz bestimmte Vorgehensweise zur Strukturierung und Lösung von Problemen im Sinn gehabt.

Spätere (ignorante ;) Generationen von Programmierern haben sich dann den Begriff jeweils so hindefiniert wie sie dachten, es passt schon.

Kays Überlegungen lassen sich in "the Early History of Smalltalk" (erschienen in HOPL II meine ich) nachlesen. Das ist aber alles grenzwertig philosophisch. Einfacher zu lesen ist Dan Ingalls "Design Principles Behind Smalltalk". Dort wird das Denkmuster (Paradigma) explorativen und iterativen Entwicklung mittels Objekten vorgestellt.

Dies sind die Grundfesten der Objektorientierung:
  • Einheitlichkeit: Alles ist ein Objekt, alles funktioniert gleich
  • Kommunikation: Objekte tauschen Nachrichten aus
Klassen, Vererbung, usw. sind alles Implementationsdetails. Nachrichten (die meisten Programmiersprachen rufen Funktionen auf, was ähnlich ist, aber konzeptionell nicht das selbe) sind der entscheide Differentiator. Erlang wäre nach Kays Vorstellung eher eine objektorientierte Sprache als z.B. Java oder C++.

Die reinste objektorientiere Sprache ist IMHO Self, ein Smalltalk-Dialekt, der neben für so unbekannten Sprachen wie Newton-Script (dieser von Jobbs ungeliebte Apple-PDA, der zu früh für die Welt kam) Vorbild für JavaScript war und dessen Erbe auch in der Sprache Io zu finden ist.

Actor, neben Smalltalk eine Insprationsquellle für Erlang, war eine weitere objektorientierte Sprache. Smalltalk selbst muss es per definitionem sein, ebenso Objective-C und Ruby als semantische Klone von Smalltalk.

Danach wird's aber dann dünn :) Flavors (frühes Lisp-OO-System) und eine reine weiterer Systeme haben versucht, Ideen der objektorientierten Programmierung mit funktionalen Konzepten zu verknüpfen, was schließlich zum Meta-Objekt-Protokoll und CLOS führte, das in abgemilderter Form dann in Dylan (damit wollte Apple mal zukünftige Mac-OS-Systeme bauen, ist aber nix geworden) realisiert wurde und sogar in Python 3 in Form generischer Funktionen schwappen könnte (den Klassenlinearisierungsalgoritmus von Dylan benutzt Python ja schon). C++ basiert eher auf Simula als auf Smalltalk und teilt sich damit den Vorfahr, aber nicht die eigentlichen Konzepte. Simula war ein Algol mit Klassen - mehr nicht.

Geblieben (und IMHO auch wichtiger) ist die Objektorientierung als Entwurfsmethode für Software - OOA und OOD sind hier zwei wichtige Begriffe neben OOP, wobei ich mich immer schwer tue, dies zu trennen und lieber nach Jacobsen (dem Erfinder der Usecases) von Entwurf und Realisierung als zwei Phasen rede.

Objekte sind hier (ich glaube, das basiert auf der Definition von Booch, es ist ewig her, das ich all diese Bücher gelesen habe als OO noch neu und shiny war und jeder der späteren Amigos ein Buch zu dem Thema schrieb) Dinge oder Konzepte die sich durch drei Eigenschaften auszeichnen:
  • Identität: Sie sind von anderen Objekten unterscheidbar
  • Zustand: Sie speichern Informationen
  • Verhalten: Sie handeln und agieren
Man erkennt (hoffentlich), dass von außen nur der dritte Punkt wichtig ist und die anderen beiden durch Verhalten realisiert werden können. Ich kann ein Objekt fragen (eine Nachricht schicken, siehe oben) "gleichst du dem Objekt da?". Das prüft dann Identität. Auch der interne Zustand ist für mich von außen nicht ersichtlich, wenn Nachrichten das einzige sind, um mit dem Objekt zu kommunizieren. Wenn ich frage "Wie ist deine Meinung zum Thema 'Füllstandsanzeige Hauptkessel'?" dann kann ich nicht erkennen, ob das Objekt einen internen Zustand befragt oder sonstwie immer den richtigen Wert kennt.

Alle OOA/OOD-Methoden (viele haben nicht überlebt bzw. sind verschmolzen, aber es gab mal Coad/Jordan, OMT, Booch, UC, OBA) sagen jetzt, man soll Objekte identifizieren (häufig klassifiziert man sie dann oder findet gleich die Klassen - an diesem Abstraktionsschritt stolpern aber viele) und ihr Verhalten definieren. Ich mag den Ansatz von CRC-Cards (von Nancy Wilkinson IIRC) wobei CRC für Class, Resposibility und Collaboration steht. Oder DDD (von Evans) was für Domain Driven Design steht. Dazu kommen noch TDD (Kent Beck) oder BDD (Dave Astels?), was aber eher für die eigentliche Implementierung gut ist und nicht so sehr für die Analyse des Problems.

Also: Objektorientierung heißt, Lösungen zu finden, indem man das Problem solange konzeptionell derart in untereinander kommunizierende Dingheiten (Objekte eben) zerlegt, bis man genug gelernt hat, es verstanden hat und eine Lösung in der gewählten Programmiersprache gefunden hat.

Stefan
Zuletzt geändert von sma am Freitag 28. Dezember 2007, 16:10, insgesamt 1-mal geändert.
poker
User
Beiträge: 146
Registriert: Donnerstag 20. September 2007, 21:44

Leonidas: http://www.python-forum.de/post-84055.html#84055
Deine Ansichten zu OOP unterschreibe ich zu 100%! Kurz: Full ACK! Selten das wir einer Meinung sind, Leonidas ;)


Costi:
Costi hat geschrieben:fuer mich ist ein object nur ein namespace. Inklusive methoden, die mit diesen namespace arbeiten.

so ist es moeglich ein dictionary als namespace zu benutzen, funktionen koennen dan diesen namespace als argument uebergeben kriegen.
dieser kann dan als this/self fungieren.
und schon hat man OOP.

und wenn die funktionen im erwaehnten dictionary gebunden sind, hat man schon 3/4 der miete
Diese Sicht, hat IMO aber nichts mit OOP zu tun. Es ist tatsächlich so wie es rayo sagt, und nutze ich oft in C. Das hat aber wie gesagt nichts mit OOP zu tun. Eher mit dem nutzen von Objekt-Like Elementen.


mitsuhiko:
mitsuhiko hat geschrieben:Da ich mich gerade mit libpurple rumschlage muss ich da gleich mal OOP in C einwerfen.
Es gibt kein OOP in C. Selbst das fungierte über den weg mit `struct`\s (Attribute, Function pointers, ...) hat nichts mit OOP zu tun.
mitsuhiko hat geschrieben: Denn die Alternative zu OOP oder dem, was ich drunter verstehe sind GOTO und globale Variablen :-)
Nicht dein ernst!? Gotos und globale Variablen sind für dich schon OOP? Das man mit Gotos exceptions "nachbilden" kann (Ich hoff ihr wisst was ich meine ;)), ist klar, aber OOP?
Hm...
mitsuhiko hat geschrieben: Drupal nutzt GoF Patterns bis zum Abwinken, hat aber keine einzige Klasse. Schaut sich aus wie ein glib Programm, halt in PHP. Gleiches gilt für so ziemlich alle glib Libraries/Programme.
Naja, design patterns gibt schon länger als OOP. Ok, GoF-Patterns im speziellen sind aus dem OOP hintergrund (und deren Unzulänglichkeiten durch Sprachen die nicht Dynamisch sind) geboren. Aber IMO - und ich denke viele sehen das auch so - sind DPs, und im speziellen auch die GoFs, nichts auf OOP beschränkt.
mitsuhiko hat geschrieben: Selbst bei funktionaler Programmierung musst du deine Daten wo ablegen. Und ob man da jetzt Closures für verwendet, oder Dicts, oder Objekte ist einerlei.
ACK. Aber das mit der Philosophie von OOP zu assozieren ist IMO fahrlässig. Nur weil man eine ähnliche Semantik hat wie bei Objekten wird es noch lange nicht zu OOP. Ich sehe es schon so wie Leonidas: Objekt Orientiert und Objekt nutzend. Sprich deine vorstellung geht vom Ojektnutzend aus und klammert die Orientierung komplett aus. Daher kann man auch zu der Aussage kommen das ``Closures`` = ``Dicts`` = ``Objekte(OP)`` ist.


BlackJack:
BlackJack hat geschrieben:Ja ORMs gehen in die deklarative Richtung. Ich dachte aber mehr an allgemeinere Werkzeuge a la Prolog, also eine Menge von Fakten und Regeln und das Ziel angeben und dann sagen "Mach mal".
Jo, das wäre was feines :) Aber da ehe schon der Funktionale Aspekt in Python abgebaut wird, glaube ich kaum das eine Mehrheit dafür sein wird, unter den Devs :(
Benutzeravatar
birkenfeld
Python-Forum Veteran
Beiträge: 1603
Registriert: Montag 20. März 2006, 15:29
Wohnort: Die aufstrebende Universitätsstadt bei München

poker hat geschrieben:Aber da ehe schon der Funktionale Aspekt in Python abgebaut wird, glaube ich kaum das eine Mehrheit dafür sein wird, unter den Devs :(
Hm, abgebaut wird da eher nichts. Gut, reduce() ist jetzt in functools, aber das wars auch schon.
Dann lieber noch Vim 7 als Windows 7.

http://pythonic.pocoo.org/
BlackJack

@poker: Man kann in C objektorientiert programmieren. Das kann man über ``structs``\s und Funktionszeiger umsetzen. Nichts anderes machen Sprachen wie C++, D, Oberon, oder ObjectPascal, nur das sie das ganze mit syntaktischem Zucker wesentlich einfacher und sicherer machen. OOP ist keine Spracheigenschaft sondern eine Vorgehensweise. Das lässt sich in fast jeder Sprache umsetzen. Mit ``struct``\s und Funktionszeigern, oder Closures und natürlich auch mit Klassen oder Objekten.

Gotos und globale Variablen sind für mitsuhiko nicht OOP. Ich lese aus dem Satz jedenfalls das genaue Gegenteil.
olliander
User
Beiträge: 11
Registriert: Samstag 12. Juli 2008, 03:08
Kontaktdaten:

Moin Moin.

Leonidas und ich hatten das Problem in einem anderen Thema angerissen (http://www.python-forum.de/topic-17032.html), deswegen nun auch hier meine Meinung...

Ich sehe es so: OOP könnte man in meinem Falle gut und gerne auch anders bezeichnen, von mir aus 'KOP' ('Kapselungsorientierte Programmierung') o.ä... Das Problem ist aus meiner Sicht einfach Folgendes: Abstraktion schön und gut, Begriffs- und Paradigmentreue ebenso... Aber OOP, wie sie heutzutage in diversen Sprachen (nicht nur Python, siehe auch Java) eingebettet wird, sollte aus meiner Sicht nicht nur auf extrem abstrakte, in der Praxis womöglich schwer nachvollziehbare Muster 'kastriert' werden... Dafür ist sie einfach zu flexibel. Und wenn es nur die Kapselung von Namensräumen ist, verbunden mit der bequemen Behandlung klasseninterner Attribute/Methoden. Wenn jemand mit dieser Auslegung von OOP zum Ziel gelangt, warum nicht? Ob das nun strikte OOP oder nicht ist... Und was gegen die quasi-Verschmelzung von prozeduralen Abläufen und Klassen einzuwenden ist, verstehe ich nach wie vor nicht... Bsp. GUI-Programmierung. Eine Anwenderoberfläche tut nunmal nichts anderes, als Befehle entgegen zu nehmen und an andere Instanzen weiterzugeben. Darf ich deswegen keine OOP verwenden? Eleganter ist es mit OOP allemal zu lösen.

Kurzum: Für mich lohnt sich OOP alleine schon deshalb, weil es elegant sein kann, die Skalierbarkeit gefördert wird und man sich um diverse Stolpersteine, die einem bspw. in der prozeduralen Programmierung begegnen können, nicht kümmern braucht, bspw. methodenübergreifende Variablenzugriffe ohne solche Späßchen wie globals.

Insgesamt muss ich also sagen... Ich denke nicht, dass man sich darüber pikieren sollte, wenn wer OOP nicht 'sinntreu' verwendet. Ich denke, es wird sich zu stark auf die Begrifflichkeit gestürzt.

Liebe Grüße,
olliander
Wadd nich passt, wird passend jemacht.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

olliander hat geschrieben:Und wenn es nur die Kapselung von Namensräumen ist, verbunden mit der bequemen Behandlung klasseninterner Attribute/Methoden. Wenn jemand mit dieser Auslegung von OOP zum Ziel gelangt, warum nicht?
Weil es für Namensräume Module gibt.In Java nicht, dort wird man zu Klassen gezwungen, also sind Klassen der große Hammer mir denen alle Probleme erschlagen. OOP ist ein Mittel zum Zweck, aber wenn ich mir ansehe was Leute für Verrenkungen mit Klassen machen nur um das zu erreichen was mit Funktionen viel einfacher wäre, dann stelle ich fest dass der Zwang zu OOP totaler blödsinn ist, wenn nicht sogar der größte Fehler von Java.

Wenn man OOP falsch verwendet kann man es gleich anders machen, denn es wird dann nicht zu klarerem Code führen sondern zu Verwirrung. GUIs sind hingegen ein Paradebeispiel für OOP, denn man hat Fenster-Objekte mit Widget-Objekten die miteinander und dem Backend kommunizieren. Smalltalk, die OO-Sprache schlechthin, hat ja eben seine Wurzeln im PARC wo auch das Konzept einer grafischen, fensterbasierten Oberfläche herkommt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
olliander
User
Beiträge: 11
Registriert: Samstag 12. Juli 2008, 03:08
Kontaktdaten:

Joar, Java ist da sowieso ein ganz eigenes Kapitel... Ich mag diese Sprache überhaupt nicht. Aber das gehört nicht hier hinein.

Prinzipielle Ansichten in allen Ehren, aber ich denke, das Problem liegt ganz woanders... Natürlich sind diverse Dinge ohne OOP möglich, aber sie sind eben ebenso gut mit OOP möglich. Nehmen wir als Bsp. eben einen Java-Entwickler, der über den Tellerrand hinaus schauen möchte (wunderbar), und jetzt eben auf Python umsteigt. Er ist nichts anderes gewohnt, als 'seine OOP'. Also wird er versuchen, sie auch in Python einzusetzen... Und diese Möglichkeit ist ihm gegeben. Finde ich an sich gar nicht verkehrt.

Und wer heute nach wie vor ohne OOP entwickelt, bspw. prozedural... Wird erstmal schief angeschaut, obwohl prozedurale Programmierung in seinem Falle evtl. durchaus sinnvoll ist. ;)

Liebe Grüße,
olliander
Wadd nich passt, wird passend jemacht.
Benutzeravatar
numerix
User
Beiträge: 2696
Registriert: Montag 11. Juni 2007, 15:09

olliander hat geschrieben:Prinzipielle Ansichten in allen Ehren, aber ich denke, das Problem liegt ganz woanders... Natürlich sind diverse Dinge ohne OOP möglich, aber sie sind eben ebenso gut mit OOP möglich.
Das hängt von der Definition von "ebenso gut" ab. Im Sinne von "es funktioniert damit auch": Ja, sicher. Im Sinne von "Es lässt sich in gleicher Qualität implementieren": Nein. Das gilt gerade für kleinere Programme nicht, kurze Skripte, die man ad hoc aufsetzt, um mal eben auf die Schnelle ein Problem zu lösen.

Es ist eben nicht immer vernünftig, für jedes noch so kleine Problem gleich eine Klasse zu entwerfen und es ist lästig, wenn eine Sprache den Programmierer zur OOP zwingt - darauf hat Leonidas ja schon hingewiesen und Java ist ein gutes Beispiel dafür. Man denke nur an ein simples "Hallo Welt" Programm in Java (und im Vergleich dazu in Python ... ).
olliander
User
Beiträge: 11
Registriert: Samstag 12. Juli 2008, 03:08
Kontaktdaten:

numerix hat geschrieben:
olliander hat geschrieben:Prinzipielle Ansichten in allen Ehren, aber ich denke, das Problem liegt ganz woanders... Natürlich sind diverse Dinge ohne OOP möglich, aber sie sind eben ebenso gut mit OOP möglich.
Das hängt von der Definition von "ebenso gut" ab. Im Sinne von "es funktioniert damit auch": Ja, sicher. Im Sinne von "Es lässt sich in gleicher Qualität implementieren": Nein. Das gilt gerade für kleinere Programme nicht, kurze Skripte, die man ad hoc aufsetzt, um mal eben auf die Schnelle ein Problem zu lösen.

Es ist eben nicht immer vernünftig, für jedes noch so kleine Problem gleich eine Klasse zu entwerfen und es ist lästig, wenn eine Sprache den Programmierer zur OOP zwingt - darauf hat Leonidas ja schon hingewiesen und Java ist ein gutes Beispiel dafür. Man denke nur an ein simples "Hallo Welt" Programm in Java (und im Vergleich dazu in Python ... ).
Hm, falls ich mich dahingehend etwas missverständlich ausgedrückt haben sollte, muss ich mich dafür entschuldigen. ;)

Ich bin grundsätzlich auch der Meinung, dass man sich genau Gedanken machen sollte, wann man etwas einsetzt, bzw. wann etwas keinen Sinn macht. Deswegen auch die Anmerkung, dass man heutzutage schief angeguckt wird, wenn man mal NICHT dem OOP-Hype getreu seine Programme/Scripte einhackt, selbst wenn nicht-OOP durchaus Sinn macht. So geht es mir nämlich oft. 'Waaas? Das ist ja wohl mal sowas von oldschool!' ... Na und?

Liebe Grüße,
olliander
Wadd nich passt, wird passend jemacht.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

olliander hat geschrieben:Nehmen wir als Bsp. eben einen Java-Entwickler, der über den Tellerrand hinaus schauen möchte (wunderbar), und jetzt eben auf Python umsteigt. Er ist nichts anderes gewohnt, als 'seine OOP'. Also wird er versuchen, sie auch in Python einzusetzen... Und diese Möglichkeit ist ihm gegeben. Finde ich an sich gar nicht verkehrt.
Richtig. Dann kann er XML zur Konfiguration verwenden, Seine Attribute mit `__` prefixen und wilde Klassenhierarchien bauen, sowie Getter und Setter implementieren etc. Aber das ist ja wohl kaum sinnvoll. Wenn man eine Sprache wechselt, sollte sich das auch im Denken niederschlagen. Ich schreibe in Scheme auch kein Python und in Java kein C. Man sollte schon idiomatischen Code schreiben, sonst ist ja die Idee eine Sprache zu nehmen die einem Arbeit erspart ad-absurdum geführt indem man sich die Arbeit eben wieder aufhalst, die einem die Sprache eben abnehmen würde.
olliander hat geschrieben:Und wer heute nach wie vor ohne OOP entwickelt, bspw. prozedural... Wird erstmal schief angeschaut, obwohl prozedurale Programmierung in seinem Falle evtl. durchaus sinnvoll ist. ;)
Von wem? Ich schaue Programme schief an die auf Teufel-komm-raus OOP nutzen, obwohl es Blödsinn ist. Und damit bin ich nicht der einzige. Natürlich schaue ich im Gegensatz auch Programme schief an, die prozedural sind, obwohl OOP dort sehr hilfreich wäre. Dogmatismus Pro-OOP und Kontra-OOP ist beides Quatsch.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
olliander
User
Beiträge: 11
Registriert: Samstag 12. Juli 2008, 03:08
Kontaktdaten:

Leonidas hat geschrieben:
olliander hat geschrieben:Nehmen wir als Bsp. eben einen Java-Entwickler, der über den Tellerrand hinaus schauen möchte (wunderbar), und jetzt eben auf Python umsteigt. Er ist nichts anderes gewohnt, als 'seine OOP'. Also wird er versuchen, sie auch in Python einzusetzen... Und diese Möglichkeit ist ihm gegeben. Finde ich an sich gar nicht verkehrt.
Richtig. Dann kann er XML zur Konfiguration verwenden, Seine Attribute mit `__` prefixen und wilde Klassenhierarchien bauen, sowie Getter und Setter implementieren etc. Aber das ist ja wohl kaum sinnvoll. Wenn man eine Sprache wechselt, sollte sich das auch im Denken niederschlagen. Ich schreibe in Scheme auch kein Python und in Java kein C. Man sollte schon idiomatischen Code schreiben, sonst ist ja die Idee eine Sprache zu nehmen die einem Arbeit erspart ad-absurdum geführt indem man sich die Arbeit eben wieder aufhalst, die einem die Sprache eben abnehmen würde.
Sag' das nicht mir... ;)
Ich versuche nur, Alltagsbeispiele reinzubringen. Sprich: Wie sieht es in der Praxis aus. Und nicht: Wie denke ich, dass es in der Praxis aussehen sollte.
olliander hat geschrieben:Und wer heute nach wie vor ohne OOP entwickelt, bspw. prozedural... Wird erstmal schief angeschaut, obwohl prozedurale Programmierung in seinem Falle evtl. durchaus sinnvoll ist. ;)
Von wem? Ich schaue Programme schief an die auf Teufel-komm-raus OOP nutzen, obwohl es Blödsinn ist. Und damit bin ich nicht der einzige. Natürlich schaue ich im Gegensatz auch Programme schief an, die prozedural sind, obwohl OOP dort sehr hilfreich wäre. Dogmatismus Pro-OOP und Kontra-OOP ist beides Quatsch.
Es geht mir hier um die Beleuchtung des allgemeinen OOP-Hype. Wie er auch alltäglich die Runde macht. Mir gehen diese selbsternannten Hüter der OOP schlicht und ergreifend auf den Zeiger, wie Du selbst schon sagtest... Mehr als kontraproduktiv ist das Ganze sicher nicht. Aber es ist nunmal (leider) Fakt, dass dies auftritt.

Also ist es, abseits des allgemein evtl. etwas zu weit reichenden Verständnis- bzw. Interpretationsbereiches von OOP, und abseits der Definitions- und "Halt' dich gefälligst an die entsprechenden Prinzipien!"-Problematik gar nicht so einfach, auf einen gemeinsamen Nenner zu kommen. Deswegen ist es auch schwierig, sich hinzustellen, und zu sagen: Du machst das falsch. Bzw. als Reaktion darauf Akzeptanz zu bekommen. Meiner Meinung nach.

Missverständnisse, Streits, etc...

Nachtrag:
Im Endeffekt legt denke ich jeder selbst fest, wann etwas für ihn Sinn macht, wann OOP aufhört und Schwachsinn anfängt etc... Und das finde ich durchaus interessant. Besonders bezgl. der Ergebnisse, die teilweise dabei heraus kommen. ^^

Liebe Grüße,
olliander
Wadd nich passt, wird passend jemacht.
DeJe
User
Beiträge: 39
Registriert: Sonntag 23. November 2008, 19:38

Ganz ketzerisch?
Für mich ist OOP nur eine andere Semantik! Letzlich ist gutes Design wichtig, das betrifft Daten, Strukturen und Funktionen. Funktionalität und Algorithmen werden durch OOP ja nicht überflüssig oder obsolet. ;)
Durch OOP wird/wurde es möglich Module besser zu kapseln, besseren Überblick zu halten. Aber ganz ehrlich, soooo ein riesen Unterschied zur funktionalen Programmierung stellt es für mich nicht dar.

wo ist der Unterschied zwischen:
foo(bar) und bar.foo() :twisted:
derdon
User
Beiträge: 1316
Registriert: Freitag 24. Oktober 2008, 14:32

Beim ersten wird die Funktion foo mit dem Parameter bar aufgerufen. Beim zweiten ist bar eine Instanz und besitzt die Methode foo, d.h. die Methode wird von bar ausgeführt (natürlich nicht wirklich, das macht der Interpreter).
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

DeJe hat geschrieben:Aber ganz ehrlich, soooo ein riesen Unterschied zur funktionalen Programmierung stellt es für mich nicht dar.
Du meinst wohl eher Prozedurale Programmierung. Funktionale Programmierung unterscheidet sich dann doch ein gutes Stück von OOP.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
DeJe
User
Beiträge: 39
Registriert: Sonntag 23. November 2008, 19:38

Jap, prozedurale Programmierung natürlich. @Leonidas. ;)

@derdon. sicher. Aber wo besteht der grundsätzliche Unterschied? Die Funktion führt eine Operation aus. Es spielt keine Rolle ob ein "Objekt" diese Operation anfordert oder diese Funktion mit einem "Objekt" (Datenstruktur) angefordert wird. Das Ergebnis bleibt das gleiche. Das Objekt (die Datenstruktur) wird in der Funktion/Methode behandelt/bearbeitet.
Letztlich ist OOP "nur" ein anderes Modell auf gedanklicher Ebene.
olliander
User
Beiträge: 11
Registriert: Samstag 12. Juli 2008, 03:08
Kontaktdaten:

DeJe hat geschrieben:Ganz ketzerisch?
Für mich ist OOP nur eine andere Semantik! Letzlich ist gutes Design wichtig, das betrifft Daten, Strukturen und Funktionen. Funktionalität und Algorithmen werden durch OOP ja nicht überflüssig oder obsolet. ;)
Durch OOP wird/wurde es möglich Module besser zu kapseln, besseren Überblick zu halten. Aber ganz ehrlich, soooo ein riesen Unterschied zur funktionalen Programmierung stellt es für mich nicht dar.
Irgendwie brachte mich das gerade auf folgenden Gedanken: Es wird verlangt, dass man OOP bevorzugt in Bezug auf Semantik mit 'Sinn' befüllt... Für mich wäre die Umkehrung mittlerweile mal richtig interessant. ^^

Sprich: Ist OOP nicht genauso interessant bzw. nützlich, wenn man sie völlig losgelöst von diversen, ich nenne es einfach mal ketzerisch so, esoterischen Interpretationen verwendet, getreu dem Motto: Klassen sind nichts anderes als Namensräume, Methoden nichts anderes als Funktionen und Attribute nichts anderes als Referenzen?

Gut, das mag etwas simpel gedacht sein, aber irgendwo ist die Frage für mich recht interessant. Und ich hoffe, das Ganze wird nicht falsch verstanden. ^^

Liebe Grüße,
olliander
Wadd nich passt, wird passend jemacht.
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

olliander hat geschrieben:Sprich: Ist OOP nicht genauso interessant bzw. nützlich, wenn man sie völlig losgelöst von diversen, ich nenne es einfach mal ketzerisch so, esoterischen Interpretationen verwendet, getreu dem Motto: Klassen sind nichts anderes als Namensräume, Methoden nichts anderes als Funktionen und Attribute nichts anderes als Referenzen?
Nenne Module Klassen und schon bist du Fertig. Denn Module sind ja genau Namensräume mit Namen (Attributen), Funktionen (Methoden) etc. Du kannst sie sogar dynamisch zur Laufzeit erstellen.

DeJe: Das ist genau das was ich in meinem ursprünglichen Posting zum Thema OOP meinte, siehe GTK+. OOP ist nicht mit einer bestimmten Syntax verbunden, das was wir in vielen Sprachen haben ist eben syntaktischer Zucker der es etwas angenehmer macht.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
BlackJack

@DeJe: Der wichtigste Unterschied zwischen ``foo(bar)`` und ``bar.foo()`` ist die Polymorphie beim zweiten Fall. Je nach dem an was `bar` gebunden ist, wird ein anderes `foo()` *automatisch* ausgeführt, wo man beim ersten Fall explizite Fallunterscheidungen in der Funktion `foo()` machen muss, was hässlich und unflexibel ist.
audax
User
Beiträge: 830
Registriert: Mittwoch 19. Dezember 2007, 10:38

es sei denn, man nutzt Multimethods, dann hat man polymorphe Funktionen. :D
BlackJack

Okay, dass wäre zumindest in Python dann aber nicht der offensichtliche Weg, den das Zen ja nahelegt. :-)
Antworten