Public Static importRunning -> Bad Design oder ok ?

[MarkusJo]

Hallo Leute,
wir haben hier eine mittelgroße EMF Application. Innerhalb dieser ist kein kaum noch zu überschauendes Gewirr von Listenern, NotificationHandler usw.

Egal was man am Datenmodell ändert.....irgendwer reagiert drauf, weil er irgendwo als Listener registriert ist.

Jetzt haben wir hier den Use Case "Import". Beim Import werden jede Menge Daten ins Modell geschrieben und wir wollen nicht dass sich manche Views, Trees usw ständig refreshen während der Import läuft.

Eine Idee war es nun einfach einen public static boolean iwo hinzuklatschen, den vor dem Import auf true zu setzen, danach auf false, und alle Views usw einfach auf diesen boolean prüfen zu lassen.

Ist das extrem böses Design oder ist das eigentlich gar nicht so selten ?


Grüße

 

[Gast2]

Ich würde das intern im Model handeln!

Einfach eine Import Variante schreiben, welche erst beim letzten Value alle Listener informiert! Auf keien Fall würde ich jeden Handler Code ändern! Es ist Sache des Models zu entscheiden wer wann über Änderungen informiert wird.

 

[MarkusJo]

Das Listener-Informieren hab ich leider nicht in der Hand....das Model ist generiert (EMF-Framework). Das passiert alles im Hintergrund und keiner weiß mehr genau an welchen Stellen überhaupt....müsste eigentlich mal alles neu gemacht werden, aber dafür ist keine Zeit.

Mir geht es aber auch gar nicht darum, sondern darum ob solch eine Public Static Variable ein "anerkanntes Verfahren" ist oder ob jeder Entwickler mit Erfahrung bei sowas direkt aus dem Fenster springt.

 

[Gast2]

Sorry war ein Missverständnis meinerseits. Hm ja ich würde Design technisch schon eher aus dem Fenster springen, die Frage ist ob ihr eine Wahl habt das anders zu regeln?

Wie gesagt die Benachrichtigung oder nicht ist Sache des Models. Wenn ihr das Model nicht in der Hand habt, entweder neu machen oder mit dem Workaround leben müssen. :/ In der Realität ist leider nicht immer alles sauber und perfekt designt und programmiert. Ich mag Singletons z.B. nicht nutze sie aber aus pragmatischen Gründen ab und an da die saubere Alternative einfach Overkill wäre.

 

[MarkusJo]

Hmm, ja.....der Overkill....vor allem wenn ständig neue Anforderungen kommen....dann werde ich im DesignMeeting zumindest mal die schmutzige Variante erwähnen....danke.

 

[BlackViruZ]

Wie wärs zumindest mit einem statisch deklarierten lock object?
Ist zwar immernoch dreckig, hat auch mehr overhead als deine boolean variante, aber wäre ein weiterer vorschlag.