Laden...

Wo verhaltensweisen speichern?

Erstellt von egrath vor 18 Jahren Letzter Beitrag vor 18 Jahren 2.237 Views
egrath Themenstarter:in
871 Beiträge seit 2005
vor 18 Jahren
Wo verhaltensweisen speichern?

Hallo,

ich steh mal wieder vor einer Designtechnischen Entscheidung - und zwar geht es mir darum dass eine meiner Applikationen zwischen zwei Betriebsmodis hin- und herschalten können muss.

Diese beiden Betriebsmodis nutzen die gleichen Methoden, die gleichen Form's etc., die unterschiedlichen verhaltensweisen werden innerhalb der Methoden der einzelnen Klassen implementiert.

Jetzt stellt sich mir die Frage wo ich am besten die Information ablege in welchem Modi sich die Applikation befindet. Zur Zeit mache ich es so, dass ich innerhalb der Haupt-Applikationsklasse eine static public Variable habe, die ich aus allen anderen Methoden bei denen sich die Implementierung unterscheidet abfrage.

Ist dies Designtechnisch ok oder gibt es hierfür eine elegantere Methodik?

Danke und Grüsse,

Egon

6.862 Beiträge seit 2003
vor 18 Jahren

Den aktuellen Modi kannst du dir direkt in ner Variablen in deiner Hauptform speichern, aber des mit den Abfragen aus den Funktionen heraus fin dich nen bissle unschön.

Recht elegant wäre z.b. sowas: Du hast ne Funktion die dir die Modi wechselt. Da du ja sagst du benutzt die gleichen Funktionen, die Verhalten sich nur unterschiedlich könntest du gut mit Delegates arbeiten. Du hast im Prinzip ja immer diese gleichen Funktionsaufrufe an die Delegates und je nachdem welche Funktion dahinter steckt, bestimmst du in deiner Funktion zum wechseln der Modi.

Weißt wie ich mein? 😁 Mal nen bissle Pseudocode:

private void switchMode(ModeType mt) {
  if(mt == ModeType.Type1) {
  // entferne Funktionsdelegates von Mode 2
  // setze Funktionsdelegates von Mode 1
  } else {
  // entferne Funktionsdelegates von Mode 1
  // setze Funktionsdelegates von Mode 2
  }
}

Ist eigentlich recht simpel und vor allem wartbarer. Du hast ein klein wenig mehr Schreibarbeit, aber z.b. ein Button, bei Click wird das Delegate aufgerufen und je nachdem welche Funktion zugewiesen ist, wird f1 oder f2 ausgeführt. Beim entwickeln hast du jetzt kürzere übersichtlichere Funktionen als eine riesige Funktion mit zig Modiabfragen.

Baka wa shinanakya naoranai.

Mein XING Profil.

egrath Themenstarter:in
871 Beiträge seit 2005
vor 18 Jahren

Hallo Talla,

danke für deine Antwort - dadurch bin ich jetzt auf die Idee gekommen wie ichs elegant lösen kann:

Im Prinzip ist das einzige was die beiden Modis unterscheidet dass in zwei Methoden andere SQL Queries benutzt werden. Ich machs jetzt so dass ich den Query in nem String innerhalb der Methoden speichern werde und diesen einfach in der Methode die das Umschalten erledigt entsprechend setze.

Manchmal sind die naheliegendsten Lösung die die am weitesten entfernt schienen...

Grüsse, Egon

178 Beiträge seit 2006
vor 18 Jahren

Nur als Ergänzung:

Den SQL Stringwürde ich dann nicht fest in den Code basteln.

Nutze dafür Settings in der config:

program.exe.config



<appSettings>

<add key="SQLString1" value="SELECT *..." />
<add key="SQLString2" value="SELECT *..." />

</appSettings>


Enjoy

Christian Arnold

1.274 Beiträge seit 2005
vor 18 Jahren

Wenn ich Formulare bastle die verschiedene Modis haben, mach ich eine variable von der ich die aktionen abhängig mache.

"Das Problem kennen ist wichtiger, als die Lösung zu finden, denn die genaue Darstellung des Problems führt automatisch zur richtigen Lösung." Albert Einstein

S
8.746 Beiträge seit 2005
vor 18 Jahren

Typischer Fall für das Strategie-Pattern.

I
1.739 Beiträge seit 2005
vor 18 Jahren

Jein? Wer weiss?
Ne simple Faktory oder was anderes könnten eine ebenfalls eine Lösung sein.
(Austausch der Query=Adapterwahl). Ich würde den Switch 2er Writeadapter bevozugen. Strategy-Pattern geht auch wäre aber in meinen Augen, für diesen Fall weniger geeignet.
Edit: Warum❔ Ein Strategy-Pattern tauscht einen Algrorithmus aus(grundlegendes Verhalten). Das sehe ich hier nicht gegeben. Ist aber auch Geschmackssache, daher mein klares Jein.