[Dune] Anmerkung Task #63

[Oliver Sander]

Hallo!
Ich finde das auch gut.  Von mir aus kann's gleich losgehen, gerne
auch ohne Übergangszeiten.

Grüße,
Oliver

************************************************************************
* Oliver Sander                **                                      *
* Freie Universität Berlin     ** email: sander at math.fu-berlin.de      *
* Institut für Mathematik II   ** phone: + 49 (30) 838 75217           *
* Arnimallee 2-6               ** fax  : + 49 (30) 838 54977           *
* 14195 Berlin, Germany        ** URL  : page.mi.fu-berlin.de/~sander  *
************************************************************************

On Wed, 21 Dec 2005, Christian Engwer wrote:

> Hallo,
>
> ich finde den Vorschlag gut. Die XXXInterface Klassen braucht man
> wirklich nicht mehr. Sehr gut gefällt mir der Vorschlag mit getRealImp
> in der GridDefault Klasse ( ich könnte mich schlagen, dass ich damals
> nicht selber drauf gekommen bin ;-) ), das ist wirklich die
> konsequenteste Lösung in Bezug auf das Typename/Class Problem von
> friend.
>
> Die XxxInterface Klassen kann man ja einfach wegschmeissen, das sollte
> niemanden weiter stören, ausser, dass das man keine Segfaults bei
> nicht implementierten Methoden mehr bekommt. Die Frienddeklarationen
> und die getRealImp kann man ja auch ohne weiteres sofort einbauen,
> lediglich die alten Frienddeklarationen für getRealEntity würde ich
> vorschlagen für eine Übergangszeit drin zu lassen, so dass etwas Zeit
> ist, die Gitter von deren Verwendung zu befreien.
>
> Tschüß Christian
>
> On Wed, Dec 21, 2005 at 05:47:38PM +0100, Robert Kloefkorn wrote:
>> Hi Duneler,
>>
>> Adrian und ich haben diese ganze Gitterschnittstellen Geschichte heute
>> nochmal durchdiskutiert. Dabei haben wir nochmal die Vor- und Nachteile
>> von Barton-Nackman in diesem Zusammenhang beprochen. Das Ergebnis ist
>> folgendes:
>>
>> Unserer Meinung nach sollte die Schnittstelle im Bereich
>> Entities, Geometries, Iteratoren mit dem Engine-Konzept verwirklicht
>> werden, d.h. so bleiben wie es ist. Dies bedeutet, das z.B. die Klasse
>> Entity die Schnittstelle bezüglich Entities beschreibt, und nur diese
>> Klasse. Die Klasse EntityInterface, die bisher eh nicht verwendet wird,
>> wird entfernt. Die Klasse EntityDefault bleibt so wie sie ist, bzw.
>> könnte in EntityDefaultImp umbenannt werden, damit klarer ist, was diese
>> Klasse leisten soll, nämlich Default-Implementierungen (wie auch immer
>> man das verwirklicht). Die Implementierungen können von dieser
>> abgeleitet werden, müssen jedoch nicht unbedingt, da die Interface
>> Konformität einzig und allein von der Klasse Entity sichergestellt wird.
>>
>> Also nochmal kurz am Beispiel Entity:
>>
>> die Klasse Entity definiert die Schnittstelle
>> die Klasse EntityDefaultImp stellt default Implementierungen zur Verfügung
>>
>> Soweit so gut. Nun sollte man noch auf MakeableEntities verzichten
>> können. Das geht so. Jede der Schnittstellenklassen bekommt eine Methode
>> getRealImp () die eine Referenz auf das intern gespeicherte Object
>> liefert. Dies methode sollte natürlich private sein, sonst hat ja die
>> Schnittstelle keinen Sinn ;). Damit man in der Implementierung trotzdem
>> auf die RealImplementation( also z.B. SEntityImp ) zugreifen kann, weil
>> man ja gegebenenfalls methoden aufrufen muss, die nicht zu Schnittstelle
>> gehören, wird für alle Schnittstellenklassen die Klasse GridDefault<..>
>> als friend definiert und dort eine methode getRealImp im Sinne der
>> jetztigen Methode getRealEntity implementiert, natürlich protected. Nun
>> können alle friend Klassen des Gitters mit Hilfe der Methode getRealImp
>> auf die Implementierung hinter der Schnittstelle zugreifen um so z.B.
>> updates auszuführen. Natürlich kann man weiterhin die Makeable Strategie
>> fahren. Man muss es jedoch nicht mehr. Ein weiterer Vorteil ist, das man
>> ganz korrekt eine Klasse als friend definiert und nicht eine methode was
>> ja bei verscheidenen Kompilern zu Problemen führte. Ausserdem muss die
>> getRealImp methode nur einmal implementiert werden. Der grösste Vorteil
>> ist jedoch, dass durch das Verschwinden von Klassen wie EntityIntercace,
>> bzw. MakeableEntityImp der Zoo an Klassen mit ähnlichen Namen etwas
>> kleiner wird. Ein weiterer Vortreil ist auch, das die
>> Gitterimplementierungen nicht geändert werden müssen. Es kann alles so
>> bleiben wie es ist, da die Zusätze nur in den Schnittstellenklassen
>> implementiert werden müssen.
>>
>>
>> Was haltet ihr davon?
>> Ich hoffe es ist einigermaßen verständlich.
>>
>> Gruß
>>
>> R
>>
>
> _______________________________________________
> Dune mailing list
> Dune at hal.iwr.uni-heidelberg.de
> http://hal.iwr.uni-heidelberg.de/cgi-bin/mailman/listinfo/dune
>