[Dune] Anmerkung Task 63

[Robert Kloefkorn]

Oliver Sander wrote:
> Hallo Robert!
> Wenn es darum geht, unseren Code einfacher zu machen, bin ich
> immer dafür.  Aber ich muß gestehen, daß mir Dein Vorschlag
> nicht in allen Konsequenzen klar ist.  Darum wollte ich mich
> nicht vorschnell dazu äußern.  Ich habe auch den Verdacht,
> daß in der Gitterschnittstelle ein paar Klassen schlicht
> überflüssig sind.  Vielleicht könnten wir das beim nächsten
> Treffen besprechen?
Hi Oli,

folgendes: Wir haben hier noch ein 2d Gitter welches von einem HiWi an
Dune angebunden werden soll. So, nun muss ich meinem HiWi erklären,
wofür er Dune::Entity, Dune::EntityInterface, Dune::EntityDefault,
Dune::MakeableEntityImp, Dune::EntityImp (wobei EntityImp jeweils für
die Implementierung des speziellen Gitters steht). Da ist erstmal
Verwirrung pur angesagt. Dabei ist mir eben aufgefallen, das man
Dune::Entity und Dune::MakeableEntityImp garnicht benötigt, weil man ja
eh nur Referenzen von Entitäten verwendet, d.h. man kommt damit aus,
wenn man als typedef in den GridTratis statt Dune::Entity
Dune::EntityDefault als Entity Klasse einträgt. Dies bedeutet dann, dass
EntityImp (also z.B. UGGridEntity) als EntityDefault interpretiert wird
und man nur Methoden der Schnittstellenklassen aufrufen kann, diese aber
dann mittels Barton-Nackman an die Implementierung weitergereicht
werden. D.h. insbesondere es ändert sich aussen garnichts. Bis auf die
Tatsache, das man auf den getRealEntity Hack verzichten kann, da die
betrachteten Entities ja schon "realEntities" sind. Bei den Iteratoren
bzw. EntityPointern geht dies nicht, da in den entsprechenden Methoden
Objekte und keine Referenzen zurückgeliefert werden. An dieser Stelle
sollte man noch ein bisschen an dem
Interface <-- Default <-- Imp
Kozept arbeiten. Prinzipiell sollte das bei allen Klassen durchgehalten
werden, damit klar ist, welches die Schnittstellenklasse (Default) ist.

Also nochmal: aus meiner Sicht gewinnt man nur, wenn für Entitäten und
Geometrien auf das Enginekonzept verzichtet, da man zwei(vier) Klassen
weniger hat und den getRealEntity Umweg spart. Der Arbeitsaufwand beträt
ca. 1Std. mit testen. Durchaus vertretbar, finde ich.

Grüßle

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