[Dune] Anmerkung Task #63

[Robert Kloefkorn]

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

-- 

  Robert Klöfkorn           <robertk at mathematik.uni-freiburg.de>

  Mathematisches Institut              Tel: +49 (0) 761 203 5631
  Abt. für Angewandte Mathematik       Fax: +49 (0) 761 203 5632
  Universität Freiburg
  Hermann-Herder-Str. 10
  79104 Freiburg

  http://www.mathematik.uni-freiburg.de/IAM/homepages/robertk