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.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.
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).
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: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.)
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.CM hat geschrieben:Durchbreche ich damit Paradigmen? Ja, und?
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.
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.JWZ, adaptiert hat geschrieben:Some people, when confronted with a problem, think “I know, I'll use classes.” Now they have two problems.