Bridge again (Re: Bridge-Pattern mit OCaml's Modul System (Re: [linux-l] Ocml vs. Java))

[Volker Grabsch]

Hallo Oliver!

On Sun, Sep 25, 2005 at 01:57:08PM +0200, Oliver Bandel wrote:
> muß man doch mit Funktoren machen.
> War meine spontane Idee doch richtig.
> Hier nun die Bridge mit Modulsystem von OCaml erledigt:
> 
> (Weil die devic keine konforme Schnittstelle haben, ist vorher noch der
>  Adapter angewendet. (Wollte das ganze Beispiel nicht nochmal umbauen))
[...]
> Bridge ready. :)

Naja, eine ziemlich primitive Bridge, eher uninteressant. ;-)  Aber es
sieht korrekt aus. Du hast es genauso wie im Buch gemacht .. ebenfalls via
Vererbung und Polymorphie gelöst ... zumindest vom Konzept her. Dass diese
Sachen in Ocaml anders genannt werden, verstehe ich nicht ganz. Aber ich
kann mir denken, woher das kommt: Sie gehen dichter an die Mathematik,
und Funktoren zwischen Kategorien sind im Wesentlichen das, was in Ocaml
Funktoren zwischen Modulen bedeuten.

Damit bestätigt sich meine Vermutung: Das heiß gepriesene Modulsystem
von Ocaml ist letztlich eine Implementierung von Vererbung und
Polymorphie auf Ebene der Module (statt auf Klassen-Ebene).

In Ruby werden übrigens Module und Klassen einheitlich behandelt, d.h.
Klassen sind dort lediglich Module mit ein paar mehr Features. Wenn ich
mich nicht irre, sind damit all die Features, die du in Ocaml angeführt
hast (außer der statischen Typisierung natürlich) in Ruby genauso
möglich. Und auch in Python, wenn man diese Dinge nicht in Module,
sondern in Klassen verpackt, was sowieso eher üblich ist.

Bei der Bridge ist die Schwierigkeit aber nicht unbedingt das Aufbauen
zweier paralleler Klassenhierarchien, deren Wurzelklassen verbunden
sind. Dieses in Sprache X zu bewerkstelligen ist "straight forward",
wenn einem Vererbung und Polymorphie in irgendeiner Form zur Verfügung
stehen. Nein, die wahre Schwierigkeit besteht darin, sein Modell
wirklich in diese Form zu bringen, bzw. auf die Idee zu kommen, das
konseuquent wirklich so zu machen, um in der einen Hierarchie die
Features zu entwicklen und in der anderen Hierarchie die
Implementierungen.

Aber es bringt ein paar Einschränkungen mit, denen ich mich in meinem
Fall nicht unterwerfen kann. Daher besagtes "Typen-System" oder
"Feature-Handler", oder wie auch immer man das nennen mag. Dazu aber
mehr, wenn ich wirklich was in der Hand habe, über das ich schreiben
kann.


Viele Grüße,

	Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR