[Dune] Anmerkung Task 63

[Oliver Sander]

Noch ein 2d-Gitter?  Interessant.  Was kann das denn?

Wenn die von Dir beschriebenen Änderungen so einfach sind,
und Du es eilig hast, dann schlage ich folgendes vor:  Ihr
macht einen separaten CVS-Ast auf.  Dort ändert Ihr die
Schnittstelle so wie es Euch passt.  Wenn dort alle Tests
noch laufen und es auch sonst nicht so unvorhergesehenen
Problemen kam wird es sicher viel leichter, den Rest der
Truppe zu überzeugen.

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 Fri, 16 Dec 2005, Robert Kloefkorn wrote:

> 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
>
> _______________________________________________
> Dune mailing list
> Dune at hal.iwr.uni-heidelberg.de
> http://hal.iwr.uni-heidelberg.de/cgi-bin/mailman/listinfo/dune
>