Würde man in der Praxis eine Form für zwei versch. Verwendungszwecke nutzen?

Hallo,

dies ist nur eine Verständnisfrage, die ich so für mich nicht wirklich geklärt bekomme.

Nehmen wir mal an, ich habe in einem WindowsForms-Projekt eine Form, über die der Benutzer Vorname und Name eingeben kann (z. B. über je eine Textbox). Der Zweck der Form ist also die Eingabe/das Anlegen eines (Benutzer-)Vor- und Nachnamens.

Nehmen wir weiter an, ich möchte den Vor- und Zunamen editieren - ich könnte besagte Form also aufrufen und die entsprechenden Textboxen mit Vor- und Zuname besetzen, so dass sie entsprechend geändert werden könnten.

Meine Frage: macht man in der Praxis sowas? Oder würde man - vorausgesetzt man möchte dem User das Editieren seiner Eingabe genauso präsentieren - eine zweite Form anlegen (Form2), die optisch eben Form1 entspricht?

Meine Frage gründet auf folgende Überlegung: immer wieder habe ich jetzt im Bezug auf Klassen gelesen, eine Klasse solle nur 1 Funktion erfüllen. Andererseits soll Code so angelegt sein, dass eine gewisse "re-usability" gewährleistet ist. Ich weiß, ich strapaziere jetzt arg das Prinzip von wiederverwertbarem Code, indem ich es auf die Präsentation ausdehne - rein praktisch würde das ja funktionieren, andererseits würde meine Klasse Form1 zwei Zwecke erfüllen: Daten anlegen, Daten editieren. Also doch 2x dieselbe Form erstellen?

Gruß
Vorph

Diese von dir angesprochene Form sollte lediglich die Benutzereingaben entgegennehmen und bereitstellen. Das Speichern selber wird von dort nur angestossen aber nicht selber ausgeführt.

Das wäre auf jeden Fall richtig getrennt.

Ob das Speichern dann eine Neuanlage oder eine Aktualisierung ist ist ja schon fast unerheblich.

Wenn also diese Form beides abdecken kann (Neuanlage, Änderung zeigen die gleichen Felder und gleiche Validierungslogik), warum nicht für beides verwenden.

Diese von dir angesprochene Form sollte lediglich die Benutzereingaben entgegennehmen und bereitstellen.

Ein nicht unerhebliches Detail, das ich vergessen hatte! Tatsächlich braucht es dann ja eine Methode, die einen Parameter entgegennimmt, der entscheidet, ob es sich um eine Neueingabe oder eine Bearbeitung handelt (ein bool im Konstruktor zum Beispiel).

Ich könnte mir also folgendes vorstellen:

public partial class NewOrEdit: Form
{
    public bool taskSwitch;

   public NewOrEdit(bool isNew)
   {
     InitializeComponent();
     if (isNew)
        taskSwitch = true;

     taskSwitch = false;
   }
}

So könnte z. B. der Konstruktor einen bool entgegennehmen, der letztlich darüber entscheidet ob ein neuer Eintrag stattfindet, bzw. ob ein Eintrag bearbeitet werden soll.
Ich habe jetzt noch einen public bool taskSwitch deklariert, so dass z.B. ein Button später auf Grundlage dieses bools entsprechend z. B. eine Methode CreateNewEntry() im einen Fall, bzw. EditEntry() im anderen Fall aufrufen könnte.

Soweit decken sich unsere Ansichten also?

Wenn also diese Form beides abdecken kann (Neuanlage, Änderung zeigen die gleichen Felder und gleiche Validierungslogik), warum nicht für beides verwenden.

Genau an dem Punkt bin ich mir unsicher, denn: ich verpacke ja 2 (wenn auch ähnliche) Funktionen / Zuständigkeiten / Aufgabenbereiche (wie immer man das jetzt nennen will) in **einer **Klasse! Soweit ich das aber verstanden habe, ist die "gute Schule" objektorientierter Programmierung die, das eine Klasse immer nur eine Aufgabe (ein Task) erfüllen sollte und demnach ihre Member auf jenen (einen) Zweck hin ausgerichtet sein sollten. Eben kein "multi-perpose" Szenario.

Vielen Dank, Sir Rufo, für deinen Beitrag - ich bin gespannt, ob es noch Zweitmeinungen gibt 😉

Deine Form erfüllt ja auch nur eine Aufgabe. Sie ist das Benutzerinterface für die Bearbeitung einer Benutzer-Instanz.

Ob es sich bei der Benutzer-Instanz um eine neue oder bestehende handelt ist nur ein Flag in der Benutzer-Instanz.

Beim Speichern wird anhand dieses Flags dann von der Speicher-Klasse entschieden ob ein Insert oder Update erfolgt. Hat dann aber nichts mehr mit deiner Form zu tun.

Ganz nebenbei

     if (isNew)
        taskSwitch = true;

     taskSwitch = false;

Was ist taskSwitch nach dieser Methode? ... IMMER false!
Den selben Zweck erfüllt übrigens ganz simpel taskSwitch = isNew;

Ich bin der selben Meinung wie Sir Rufo.

Soweit ich das aber verstanden habe, ist die "gute Schule" objektorientierter Programmierung die, das eine Klasse immer nur eine Aufgabe (ein Task) erfüllen sollte und demnach ihre Member auf jenen (einen) Zweck hin ausgerichtet sein sollten.

In der Praxis wirst du merken dass du nicht immer alles zu 100% befolgen kannst was die Theorie rät 😉
Ein weiterer Grundsatz ist nämlich nichts doppelt zu machen. Also keine zwei identischen Forms zu erstellen. Wenn du das eine anpasst musst du das andere anpassen. Denkst du immer daran? Wahrscheinlich nicht.

Lege als Aufgabe fest: Das Form soll Userdaten eingeben lassen und je nach Vorgabe in einem neuen Objekt zurückgeben oder ein bestehendes ändern. Diese beiden sehr ähnlichen Dinge im selben Code zu erledigen kostet dich weit weniger Zeit und Aufwand um dich später erneut darin einzulesen, als Code doppelt zu schreiben.

Vielen Dank Sir Rufo und chilic - damit hat sich der Denkknoten gelöst, diese Argumentation überzeugt mich 🙂

Beim Speichern wird anhand dieses Flags dann von der Speicher-Klasse entschieden ob ein Insert oder Update erfolgt. Hat dann aber nichts mehr mit deiner Form zu tun.

Ähnlich hatte ich ja auch argumentiert - ich hätte es also vorher merken können 😁

Vielen Dank!

Ließe sich die Entscheidung, ob Neu oder Editieren, nicht durch die Poperties leicht festlegen ?

Letztlich muß man ja die Angaben des Benutzers irgendwie aus dem Form wieder heraus bekommen. Üblicherweise nimmt man dafür ja Properties. Wenn man denen einen Setter verpaßt und dann von "außen" sozusagen die Poperties befüllt, steht doch automatisch fest, das ein Editieren vorliegt und man kann bereits im Setter seine Flags entsprechend setzen...

Dann muss das Formular nicht wissen ob editiert wird oder eine neue Eingabe erfolgt. Es zeigt das im Eingabefeld an was gesetzt wurde. Wenn nichts gesetzt wurde bleibt es leer. Was dann mit dem ausgelesenen Wert passiert ist dem Formular auch egal.

Sofern es ein Datenobjekt gibt würde ich allerdings darüber nachdenken, das Formular mit dem Objekt aufzurufen. Es trägt dann die Daten aus dem Objekt in die Eingabefelder ein - leer oder gefüllt - und beim bestätigen wieder zurükck ins Objekt. Dann belässt man formularabhängigen Code im Formular.