Seite 2 von 4

Verfasst: Dienstag 4. Dezember 2007, 14:16
von Leonidas
SchneiderWeisse hat geschrieben:Für mich als Programmieranfänger ist sowieso noch überhaupt kein Vorteil in der OOP ersichtlich...
Habe bisher nur mit JavaScript gearbeitet und dort auch ausschließlich funktional programmiert.
Ich denke du meintest prozedural, oder? Funktionale Programmierung ist noch einmal etwas anderes, es beschriebt quasi das Gegenteil von Imperativer Programmierung und geht von einem eher mathematischen Ansatz aus - eine Funktion hat einen Eingabewert und einen Ausgabewert und wenn du das gleiche eingibst dann kommt das gleiche wieder raus. Klingt jetzt nicht spannend, aber es heißt dass die Funktionen von einem Aufruf zum anderen Aufruf keinen Zustand speichern. Ist also das Gegenteil von Objekten, die eben genau dazu da sind den Zustand der durch sie abgebildeten Muster darzustellen.
Mit JavaScript kann man natürlich auch, zumindest zu einem gewissen Teil funktional arbeiten, aber spätestens wenn du etwas an HTML ändern willst, ändert die bearbeitete Seite den Zustand. Sowas ist dann ein Seiteneffekt. Imperative Programmierung beschäftigt sich eben mit den Seiteneffekten.

Das Beispiel eine Datei zu speichern demonstriert das ganz gut: wenn ich in Python write() auf einem Dateiobjekt aufrufe, dann gebe ich in die Funktion Daten ein und bekomme None zurück. Aber die Funktion hatte eben den Seiteneffekt, dass sie die eingegebenen Daten in die Datei geschrieben hat. Funktionale Programmierung möchte möglichst ohne Seiteneffekte auskommen. So eine rein funktionale Sprache wäre Haskell, wo du Seiteneffekte nur über ein Konstrukt namens "Monade" bekommst. Dieses jetzt auszuführen wäre aber arg komplex und ich glaube nicht dass ich es gescheit erklären könnte. Soviel nur, dass viele funktionale Sprachen hybride sind, d.h. sowohl funktionale als auch imperative Konzepte erlauben. Vertreter hierfür wären O'Caml (das O steht sogar für Objekte) und die Lisp-Familie (Common Lisp hat auch ein recht bekanntes Objektsystem, das CLOS).
CM hat geschrieben:Um es etwas weniger abstrakt zu machen nehmen wir mal eine Klasse "Auto" und eine Instanz "wagen". Da ist es nur natürlich den Wagen so zu bedienen: wagen.links_abbiegen(). Bei wagen.färben() fangen die Probleme schon an. Der Wagen färbt sich ja nicht selbst, oder? Also: färben(wagen).
Jetzt soll unser Auto aber kein alltägliches, stinkendes Blechmonster sein, sondern ein knuffiges Auto mit Kulleraugen in einem Kinderspiel. Da wird wagen.färben() oder .pinseln() schon eingängiger, nicht wahr? Es ist aber im Zweifel dieselbe Methode. (Das Argument läßt sich immer weiter treiben, je mehr man sich vom Abstraktem zum Intentionellem bewegt, es ist also eingentlich ein furchtbares auf Regression fußendes Argument, was ich gerne zugebe.)
Nein, färben muss gar keine externe Funktion sein, eigentlich sollte sie das wenn man es genau ansieht sogar eine Methode des Objektes sein. Denn sie verändert den Zustand - die Farbe - des Objektes. Diese Dualität hast du im Grunde in Python auch. `len()` nimmt ein Objekt und gibt dessen Länge zurück. Dabei muss es auch auf Interna des Objektes zugreifen, auf `__len__()`, d.h. also es erwartet ein bestimmtes Interface, ein bestimmtes Verhalten von dem Objekt. Im Falle von `len()` wird die Arbeit hauptsächlich auf das Objekt verlagert, in anderen Sprachen wie Ruby oder Java ist das auch ganz normal so - oft als Attribut `length`. Und `pingseln()` auf die gleiche Methode zeigen zu lassen wie `färben()` ist ebenso durchaus denkbar, möglich und in Ruby sogar gängig. Dort findest du oft Aliasnamen für bestimmte Funktionen - in Python ist der Zen dagegen, aber machen kannst du es natürlich.
CM hat geschrieben:Durchbreche ich damit Paradigmen? Ja, und?
Auch wenn, dann ist es immer noch kein Problem. Man muss eben bedenken dass Objektorientierung ein Mittel ist dem Programmierer zu helfen, sein Programm klar zu strukturieren. Nicht dazu, ihn wochenlang überlegen zu lassen, wie man ein bestimmtes Vorhaben objektorientiert umsetzt. OOP ist ein Werkzeug, kein Selbstzweck und daher ist es an einigen Stellen, wie rayo treffend gemeint hat, auch nötig und sinnvoll einige Dinge eben anders zu lösen.

Das Beispiel kennen wir alle, aber es kommt eben oft vor: es schreibt jemand ein Programm, schön prozedural. Es funktioniert auch, tut seinen Dienst gut. Nun denkt sicher der Autor "ja, das schreibe ich mal in OOP im, das ist ja Schwierigkeitsstufe zwei" (alternativ auch Programmierung 2.0) und da beginnen dann die Probleme weil bestimmte Variablen nicht zugänglich sin innerhalb einer Struktur von mehreren Klassen, so dass man letztendlich entweder alles in eine Klasse packt oder globale Klassen nutzt. Der Vorteil ist nun..ja, es gibt eigentlich keinen Vorteil. Das Programm ist objektnutzend, das Problem aber komplizierter gelöst wird als vorher.
JWZ, adaptiert hat geschrieben:Some people, when confronted with a problem, think “I know, I'll use classes.” Now they have two problems.
Zu den Design Patterns: als ich das Buch der GoF durchgeblättert habe, und einige Patterns näher angesehen habe bin ich zu dem Schluss gekommen, dass zumindest die Patterns die ich mir angesehen haben in mir in Python so nichts bringen. Man hat sie entweder anders implementiert (Visitor-Pattern etwa, sogar eleganter als in Java) oder gar nicht benötigt, weil die Sprache eine elegantere Lösung bereits bereitstellt. Daher muss man da auch vorsichtig sein und die Patterns gegenchecken ob so etwas in Python überhaupt sinnvoll ist.

Verfasst: Dienstag 4. Dezember 2007, 15:36
von BlackJack
@Leonidas: Die `IO`-Monade ganz grob erklärt: Da wird in der IO-Datenstruktur der Zustand der "Welt" vermerkt, auf den der Programmierer allerdings keinen direkten Zugriff bekommt. Es gibt also den Zustand vor dem schreiben in die Datei und einen veränderten danach. Und schon gibt's keinen Seiteneffekt mehr. Ist das nicht toll. Allerdings muss man den Zustand der Welt immer mit herumreichen, das heisst sämtlicher IO-Code muss dann mit Typen der IO-Monade arbeiten.

Bei dem `faerben()` ist die Frage, ob das überhaupt eine Methode sein muss und nicht einfach nur ein Attribut `farbe` reicht.

OOP als Werkzeug sehe ich genau so. Darum mag ich Sprachen, die mehrere Paradigmen unterstützen. Es gibt eben Einsatzgebiete wo jeweils prozedural, funktional oder OOP eine schönere, lesbarere, und wartbarere Lösung bieten als die jeweils anderen Paradigmen. Bzw. auch eine Mischung davon. Deklarative Programmierung fehlt in Python irgendwie noch. :-)

Das GoF-Buch enthält einiges was in statisch typisierten Sprachen so "schwer"/umfangreich ist, dass so viele Klassen involviert sind, dass man von einem Muster sprechen kann. Einiges davon ist in dynamischen Sprachen viel einfacher und direkter zu lösen, so dass es dort höchstens ein Idiom gibt.

@keppla: Das mit den Klassennamen ist teilweise auch Schuld von klassenfixierten Sprachen wie Java. Wo man in Python eine einfache "handle_foo"-Funktion schreibt, *muss* man in Java in der Regel eine Klasse haben, die ein `FooHandler`-Interface implementiert und die man oft mangels besseren Einfalls oder Zeit dann `FooHandlerImpl` nennt.

Verfasst: Dienstag 4. Dezember 2007, 17:33
von CM
Leonidas hat geschrieben:Nein, färben muss gar keine externe Funktion sein, eigentlich sollte sie das wenn man es genau ansieht sogar eine Methode des Objektes sein. Denn sie verändert den Zustand - die Farbe - des Objektes.
Point taken.

Verfasst: Dienstag 4. Dezember 2007, 18:59
von keppla
BlackJack hat geschrieben:Deklarative Programmierung fehlt in Python irgendwie noch.
Ist nicht das, was (teilweise mit Metaklassen) in den ganzen ORM gemacht wird, schon irgendwie deklarativ?
Ich meine sowas wie

Code: Alles auswählen

class UserTable(Table):
  id = type.Int(primary_key=True)
  name = types.Varchar(length=50, nullable=False)
Klar, im Endeffekt sind in Python auch Klassen irgendwie Anweisungen, aber ich finde, das geht schon in richtung deklarativ (im Sinne von: ich sag nicht, wie es gemacht wird, sondern was ich haben will)
Das GoF-Buch enthält einiges was in statisch typisierten Sprachen so "schwer"/umfangreich ist, dass so viele Klassen involviert sind, dass man von einem Muster sprechen kann. Einiges davon ist in dynamischen Sprachen viel einfacher und direkter zu lösen, so dass es dort höchstens ein Idiom gibt.
Jo, das finde ich auch sehr auffällig. Einige Pattern sind schlicht Sinnlos in dynamischen Sprachen (typesafe enum z.B.), andere sozusagen "first level patterns".
Packages sind Singletons, Klassen sind factories, Funktionen "delegates", "callbacks", was-auch-immer...
@keppla: Das mit den Klassennamen ist teilweise auch Schuld von klassenfixierten Sprachen wie Java. Wo man in Python eine einfache "handle_foo"-Funktion schreibt, *muss* man in Java in der Regel eine Klasse haben, die ein `FooHandler`-Interface implementiert und die man oft mangels besseren Einfalls oder Zeit dann `FooHandlerImpl` nennt.
Ja, ich kenne Java. Früher (=vor python) hielt ich das sogar für ne gute Idee...
Auch ich hab schon den ein oder anderen Handler oder Manager geschrieben. In vielen Fällen ist das ja auch ok (man soll laut tipp ja nur "nachdenken"), das Ding hat ja exakt diesen einen Zweck.
Aber gerade Objekte, die nicht sonderlich spezifisch sind, haben imho die Tendenz zu "god-objects" zu Eskalieren, weil man bei keiner Erweiterung wirklich sagen kann "dafür ist das Objekt nicht zuständig".

Verfasst: Dienstag 4. Dezember 2007, 19:41
von BlackJack
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".

Verfasst: Sonntag 9. Dezember 2007, 19:20
von sma
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

Re: Was ist OOP eigentlich?

Verfasst: Montag 10. Dezember 2007, 00:03
von poker
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 :(

Re: Was ist OOP eigentlich?

Verfasst: Montag 10. Dezember 2007, 00:24
von birkenfeld
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.

Verfasst: Montag 10. Dezember 2007, 00:59
von 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.

Verfasst: Mittwoch 10. Dezember 2008, 14:38
von olliander
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

Verfasst: Mittwoch 10. Dezember 2008, 14:49
von Leonidas
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.

Verfasst: Mittwoch 10. Dezember 2008, 14:59
von olliander
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

Verfasst: Mittwoch 10. Dezember 2008, 15:28
von numerix
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 ... ).

Verfasst: Mittwoch 10. Dezember 2008, 15:38
von olliander
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

Verfasst: Mittwoch 10. Dezember 2008, 18:46
von Leonidas
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.