Re: [Ftraq-devel] LgSettings und TransferQueue

[Steffen S. <ste...@gm...>]

Erik Moeller wrote:

>Am Fre, 2002-06-21 um 01.21 schrieb Steffen Sauder:
>
>  
>
>>Die unteren Schichten sollten die darüber nicht kennen 
>>(->3-Schichten-Modell). Wenn sie
>>es doch tun müssen, dann aber bitte heimlich und nicht noch in den 
>>Kommentaren mit
>>den Fingern draufzeigen ;). Besser wäre auch hier wenn sich die 
>>LgSchicht die Werte aus
>>der DbSchicht mit gettern holt, und wenn nötig mit Observer Pattern dazu 
>>aufgerufen wird.
>>    
>>
>
>Die Db-Schicht muss zwar auf das Lg-Objekt zugreifen, aber sie braucht
>eigentlich die setter zum Zuweisen der Listen nicht, wenn die Lg-Schicht
>leere Standardlisten verwendet.
>
Statt leere Standardlisten zu verwenden müsste das Lg-Settings objekt 
beim Initiliaisieren
einfach das Db-Settings-Objekt erzeugen und sich von ihm genau jene 
Listen holen, die du
mit den settern übergeben wolltest

> Ich meine, es ist aber wenig logisch,
>elementare Datenhaltungsobjekte wie Maps und Listen unbedingt in die
>Db-Schicht zu stecken. 
>
richtig, ich meinte auch nicht daß alle Werte aus der Db-Schicht 
gehalten werden holen sollen,
nur sollte die Entnahme der Listen und Maps aus der Db-Schicht(zu Beginn 
oder beim Rollback) von
den LgSettings ausgehen mit (z.B. dbSettings.getStringOptionMap()) und 
nicht andersherum

>Der urpsrüngliche Aufruf, der dazu führt, dass die Db-Schicht die
>Lg-Schicht bedient, geht aber von der Lg-Schicht an die Db-Schicht
>(open).
>
wenn dieser open Befehl sich die aktuellen Einstellungen aus den 
Db-Settings holt,
wozu denn dann noch die Setter?

>>2. Die typsicheren Maps und Listen sind zwar eine feine Sache, aber 
>>irgendwie schöner
>>wäre es doch, die Implementierung als Listen und Maps nicht nach außen 
>>preiszugeben,
>>sondern stattdessen nur Methoden zum logischen Zugriff ohne Hinweis auf die
>>verwendete Implementierung  bereitzustellen
>>
>>    
>>
>Hm, komplett verpacken werde ich die Listen wohl nicht, da man dann
>wieder viele Methoden verbergen müsste (keys(), values() usw.).
>
Wer braucht außerhalb der Klasse diese Methoden? Und sind die Listen 
threadsicher, oder muß sich
der Benutzer selber um die Synchronization kümmern? wenn ich zum Beispiel
alle TextFileExtensions durchlaufen will (z.B. um sie in der Gui 
anzuzeigen)., müsste ich jetzt so vorgehen):

        String_List fileExtensionList = 
ftraq.Main.getLgApplication().getSettings().getTextExtensionList();

        // um zu verhindern, daß bei gleichzeitiger Änderung der Liste durch
        // einen anderen Thread eine ConcurrentModificationException 
ausgelöst wird
        synchronized(fileExtensionList) {
            String_List.Iterator it = fileExtensionList.listIterator();
            while (it.hasNext()) {
                String fileExtension = it.next();
                doSomethingWith(fileExtension);   
            }
        }

Übersichtlicher wäre doch etwas wie hier:

        String[] textExtensions = 
ftraq.Main.getLgApplication().getSettings().getAllTextExtensions[];
        for (int i=0; i<textExtensions.length; i++) {
            doSomethingWith(textExtensions[i]);
        }

Genauso fände ich es praktischer anstatt an vielen Stellen immer die 
gleiche Zeile

 if 
(fileExtensionList.contains(fileNameToTest.substring(fileNameToTest.lastIndexOf('.')+1).toLowerCase()) 
{  doKram() }

zu schreiben, stattdessen eine ausgelagerte Funktion zu haben:

if (lgSettings().hasFileNameTextFileExtension(fileNameToTest)) {doKram() }

Neben diesen Funktionen bräuchte ich nur noch add- und 
removeTextFileExtension(String i_extension).
Auf alle anderen Funktionen der Liste kann ich verzichten.

> Gerade
>das mit dem Null-Pointer kann man ja auch in der Liste als Exc
>realisieren. 
>
richtig.

>Da wo es Sinn macht, kann man aber noch abgeprüfte Methoden
>hinzufügen. Der Nutzer kann dan halt immer auch die unsicheren
>verwenden.
>
wie gesagt, da wo es nicht benötigt wird, fände ich es sinnvoller die 
Listen und Maps
in LgSettings zu verstecken, unteranderem wegen des Problems des 
gleichzeitigen
Zugriffs von mehreren Threads. Wie würde zum Beispiel die Db-Schicht 
reagieren
wenn während eines commits von zweit Threads gleichzeitig neue Elemente in
die Listen und Maps der Logikschicht eingetragen werden? Eine Sperrung der
Daten während des commits ist meiner Meinung nach am einfachsten möglich,
wenn jeder Veränderung der Daten nur über eigens dafür gedachte Methoden
in LgSettings passiert, die die Kontrolle über die Synchronization des 
Zugriffs auf
die Maps und Listen haben.

gruß
Steffen