[linux-l] Re: SW-Design / Modules vs. Objects/Classes

[Axel Weiß]

Peter Ross schrieb:
> On Sun, 23 Oct 2005, Axel Weiß wrote:
> >>                 | FP-approach:            | OO-approach:
> >>
> >> 
> >> ---------------|-------------------------|-------------------------
> >> adding a new   | add one function,       | Must edit all classes,
> >> operation over | other functions         | adding a new method
> >> things         | unchanged               | to every class
> >> ---------------|-------------------------|-------------------------
>
> In Objective-C kann man nachfragen, ob die Methode existiert
> (respondsToSelector).
>
> Wenn ja, fuehrt man die Methode aus, wenn nicht, halt nicht..

Hi Peter,

was willst Du damit sagen? Was hat das mit dem Thema FP-/OO-Sicht zu tun?

> So kann man z.B. in eine Liste alle moeglichen Objekte dreintun. Und
> wenn diese Liste benutzt wird, um etwas zu malen, werden die Objekte
> nach einer Paint-Methode gefragt, wenn es sie gibt, kann man das
> Objekt malen, indem man die Methode aufruft.
>
> Dazu muessen die Objekte nicht einmal einen gemeinsamen Vorfahren
> haben.

Es wäre aber besser (aus OO-Sicht), sie hätten einen gemeinsamen 
Vorfahren. Wenn dieser die Paint-Methode virtuell bereitstellt und eine 
leere Implementierung dafür hat, braucht man keine Abfrage, ob die 
Methode existiert. Man ruft sie einfach auf. Objekte (Klasseninstanzen), 
die eine Paint-Methode haben, dürfen sie jetzt anwenden, Objekte, die 
keine haben, werden einfach übergangen.

> Das entspricht z.B. dem Messaging bei gaengigen GUIs. Wenn ein Fenster
> z.B. eine Message geschickt bekommt, reagiert es nur, wenn es eine
> Methode hat, um darauf zu reagieren.
>
> Ich denke, wie man an verschiedenen Beispielen sieht, ist die Tabelle
> so starr nicht, es ist von den Features einer konkreten Sprache
> abhaengig.

Das sehe ich anders. Es ist Zweierlei, ob man Konzepte umsetzt oder 
Sprachfeatures nutzt. Konzepte sind an bestimmte Sichtweisen geknüpft 
und lassen sich im Zweifelsfall auch in C oder Assembler umsetzen. 
Zugegeben, bei manchen Konzepten wäre das ziemlich mühsam, aber darauf 
kommt es mir nicht an. Wenn eine Sprache für ein gegebenes Konzept keine 
direkte Unterstützung hat, lässt sich das Konzept dennoch durch 
entsprechende Programmierdisziplin umsetzen. Ich setze seit Jahren 
erfolgreich OO-Konzepte mit C um (Kapselung, Vererbung, spätes Binden 
von Methoden, Polymorphie).

Die Tabelle ist, denke ich, nicht als starres Schema zu verstehen, 
sondern als eine Gegenüberstellung der Konsequenzen zweier Sichtweisen, 
bezogen auf die Wiederverwendbarkeit von Code. Das Interessante dabei 
ist, dass die Codeerweiterung in zwei Richtungen geschehen kann 
(Hinzufügen von Merkmalen, Hinzufügen von Aktionen), und jede Sichtweise 
für eine Art der Erweiterung prädestiniert scheint. So lässt sich Code, 
der nach OO-Konzepten strukturiert ist, besonders gut durch Hinzufügen 
neuer Klassen (Merkmale) erweitern - FP-Code besonders gut durch 
Hinzufügen neuer Aktionen. Die Tabelle sagt nichts über 
Programmiersprachen oder deren Features.

Gruß,
			Axel