Adaptor-Pattern mit Ocaml's Module System (Re: [linux-l] Ocml vs. Java)

[Oliver Bandel]

On Fri, Sep 23, 2005 at 03:52:14PM +0200, Volker Grabsch wrote:
> On Fri, Sep 23, 2005 at 08:26:01AM +0200, Oliver Bandel wrote:
[...]
> Du findest diese Muster überall, und deshalb verstehe ich nicht, wieso
> du sie als antiquiert bezeichnest. Du hast doch genau dieses Muster
> auch bei Ocaml angewendet.


Dieses Muster war ja auch Vorgabe!

Vorgabe: "Implementiren sie dieses Muster M nicht mit X sondern mit Y."

Vorher:  M mit X implementiert
Nachher: M mit Y implementiert.


Das sagt aber nichts darüber aus, ob die GESAMT-Herangewensweise auch in dieser
Weise sinnvoll ist.

Der Untertitel des Buches "Design Patterns" heisst:
"Elements of Reusable Object-Oriented Software".

Da steht also: Wir haben ein Problem, ads während der OO-Implementierung
auftauchte und dieses Problem soll gelöst werden.

Da steht nicht: Wir haben ein problem und schauen mal, ob wir es mit OO
oder anders lösen.

Die Notwendigkeit für bestimmte Patterns tauchen abhängig davon auf, ob
das Problem via OO, imperativ oder funktional gelöst wird.

Wenn man dann eine Problemlösung heraus greift und diese dann mit
Moduln statt OO löst (was zumindest schon mal Laufzeitoverhead
weg nimmt), dann ist aber dieses Pattern schon die Vorgabe.

Was ich eigentlich kritisiere ist ja, daß im Allgemeinen, wenn man sich mal
umschaut, immer auf OO fixiert geschaut wird, daß man die Probleme
löst.
DAS ist es, was ich eigentlich als antiquiert ansehe: Die funktionalen Sprachen
sind in den letzten Jahren aus ihrer verschlafenen Zeit heraus und langsamen
Code produzieren sie auch nicht mehr. (Oder anders gesagt: einige sind recht flott.)


Daß man immernoch mit irgendwelchen OO-problemen und Patterns um sich wirft, die bei einem
anderen Ansatz viell. garnich in dieser Weise aufgetaucht wären, DAS ist es, was ich
beknackt finde.

Da brauchst Du Dich dann ja wohl NICHT angesprochen fühlen, denn Du scheinst ja,
wenn ich das nun richtig sehe, nicht grundsätzlich gegen funktionale
Programmierung zu sein.
Aber wenn ich mich mal auf dem Programmiermarkt (Industrie z.B.) umschaue,
dann habe ich da noch nichts von non-OO gelesen.
Es gibt zwar schon die eine oder andere Firma, die einen Erstkontakt zu z.B. OCaml hatte.
Aber das ist noch rar.

Ausserdem sollte man auch mal gut heissen, wenn Leute aus Ihrer Erfahrung
heraus sagen, daß eine Programmierung mit funktionalen Features extrem
leistungsfähig ist.

Die Beispiele im Design Pattern Buch sind sowohl für den Adapter als auch die Brücke
beides GUI-Beispiele. Bei GUIs macht OO IMHO auch Sinn (es gibt auch funktionale
Ansätze, aber das ist wohl noch als zur Zeit kaum erforscht/rudimentär anzusehen).

Deswegen ist es auch schwer, wenn man so ein eng umgrenztes Gebiet sich betrachtet,
das durch eine bestimmte Programmierweise gut abgedeckt ist, in einer anderen
Programmierweise durchzuführen.

Also: wenn man in einem hauptsächlich OO-Gebiet ein funktionales Äquivalent sucht,
wird es ebenso unpassend, wie wenn man in einem hauptsächlichen FP-Gebiet mit
OO heran geht. (Ersteres ist in manchen unviersitären Fachbereichen wohl
Forschungsgegenstand, Letzteres ist in der Industrie Standard. Beides ist Murks.)

In sofern sind nicht die Design Patterns antiquiert, aber es ist antiquiert, alles
nur durch die OO-Brille zu sehen.

Um Vergleiche anzustellen, was denn auf welche Weise vielleicht besser gelöst werden kann,
macht ein Fokussieren und Nachimplementieren vorgefertigter Lösungen für einen
bestimmten Anwendungsfall (selbst, wenn diese Lösung darüber hinaus weist)
keinen Sinn. Man braucht die sog. Real-World Probleme.

Wenn man nur EINE Lösungsweise nutzt, also nur ein Programmierparadigma anwendet,
kommt man an gewissen Punkten nicht weiter. Das ist nicht nur dogmatisch, sondern
wird auch Bloatware.

Deswegen sind Programmiersprachen wie OCaml so sinnvoll: man hat viele Möglichkeiten
zur Auswahl und kann die geeignete auswählen!

Das setzt aber voraus, daß man seinen Blick aufweitet und nicht bei pur-OO
und OO-Design-Patterns bleibt.

DAS ist das, was ich meine.

Das scheinst Du wohl in Python so zu machen.

Aber IMHO sollte man dynamische Sprachen nur dann anwenden, wenn man
genau diese Features auch braucht. Weil einem sonst unnötig die
statischen-/compilierzeit- Checks verloren gehen, die einem
enorm helfen, Fehler im Vorfeld auszumerzen.

Gruß,
   Oliver