Ist es OK, um eine überlastung ShowDialog() so, dass ein Kind die form der Informationen liefert als ein out-parameter?

In einer früheren Frage über gewusst wie: zurückgeben einer Zeichenfolge aus einem dialog-Fenster, yapiskan vorgeschlagen überlastung des untergeordneten Formulars ShowDialog () - Methode, um einen out-parameter.

Meine Frage ist, ob oder nicht, das ist ein guter Ansatz in C#.

Hier finden Sie einige Beispiel-code, basierend auf yapiskan Vorschlag. In der child-form (in diesem Beispiel, es ist eine form mit einer textbox drauf), müssen Sie nur fügen Sie die ShowDialog-überlast-und ordnen Sie UI-Werte der out-parameter:

public DialogResult ShowDialog(out string s)
{
    DialogResult result = this.ShowDialog();
    s = this.textBox1.Text;
    return result;
}

Und zeigen Sie das Formular, und rufen Sie die Eingabe von text, Sie dies tun:

using (CustomDialog frm = new CustomDialog())
{
    string s;
    if (frm.ShowDialog(out s) == DialogResult.OK)
    {
        //do something with s
    }
}

Einen Vorteil, den ich mir vorstellen kann ist, dass dieser Ansatz zwingt den Benutzer, der CustomDialog Formular aus, um die Informationen, die es enthält, durch die form der ShowDialog-Methode (anstelle von einem wer-weiß-was-es-genannt-Methode wie GetMyData() oder so).

InformationsquelleAutor MusiGenesis | 2008-11-11
  1. 7

    Besser eine Öffentliche Eigenschaft/Methode und Holen Sie sich die Informationen.

    Was würden Sie tun, wenn Sie müssen 3..4..5 Informationen, mit 5 Parametern aus? Mehr sauber zu haben Accessoren, um Ihre Informationen aus dem Dialog.

    • Ich bin mir nicht sicher. Mit den Parametern im Dialogfeld, können Sie nicht sicherstellen, dass der Benutzer sich bewusst ist, welche Informationen verfügbar ist (z.B. könnte er vermisse die GetFullName () - Methode und schreiben, seine eigenen statt). Mit alles in einem ShowDialog überlast, er kann es nicht verfehlen.
    • zu klären: könnte er schreiben, seine eigenen durch die Kombination der dialog ist GetFirstName und GetName Methoden.
    • Wenn er es braucht, die er bekommen wird, den accessor, um die Informationen. Er könnte nur nicht immer müssen Informationen. In diesem Fall wird er in Ordnung sein mit accessor. Ansonsten, mit aus, könnte er Sie brauchen nicht den string, sondern hätte, um eine variable zu erstellen... für nichts...
    • Ein Vorteil der immer alle Infos aus einer Methode (entweder eine ShowDialog überlastung oder GetData oder so) ist, dass, wenn Sie einen parameter hinzufügen alle aufrufenden Klassen geändert werden müssen, sich darüber bewusst zu sein, um zu kompilieren.
    • Der andere Punkt ist, dass die Verwendung von Eigenschaften ist, die die etablierten Muster hier, und Sie funktioniert gut - nicht zuletzt, weil (wie oben), kann es kein "aus" zurück, wenn der Benutzer abgebrochen hat.
    • im code-Beispiel, wäre es eine out-egal, wie der dialog geschlossen wurde. Es ist vielleicht nicht sinnvoll, aber das ist, was die Prüfung für DialogResult.OK, ist für.
    • Vielleicht sollte dies eine Frage gepostet, aber: wenn Sie die Eigenschaften Muster, und fügen Sie eine neue Eigenschaft, gibt es eine Möglichkeit, zu verlangen, dass der Benutzer im dialog zu behandeln, die neue Eigenschaft in irgendeiner Weise zur compile-Zeit? Tut mir Leid, wenn ich mich nicht Formulierungen deutlich.
    • Ich herzlich einverstanden mit der öffentlichen Liegenschaften Ansatz. Ich hatte gefragt, eine ähnliche Frage eine Weile zurück, und diese route war perfekt, und er macht es in hohem Grade wiederverwendbar
    • Wow. Die Zeit vergeht und jetzt bin ich vollkommen einverstanden mit Ihnen. Ich Las das und dachte, "was für ein idiot würde die Verbraucher seiner Klasse deklarieren eine Reihe von Parametern, anstatt einfach nur Eigenschaften Lesen?" Dies ist vielleicht das dümmste, was meine Vergangenheit selbst immer schrieb.

    InformationsquelleAutor Patrick Desjardins
  2. 5

    Sollte es nicht OK sein, da .net framework verwenden, die nicht mit diesem design. Im Fall der OpenFileDialog-Klasse, es hat einen parameterlosen ShowDialog () - Methode der Rückkehr ein DialogResult. Sobald diese Methode aufgerufen, die die Benutzer sollen, um die ausgewählten Dateien mit den Dateinamen, die Dateinamen, SafeFileName und SafeFileNames Methoden.

    Lassen Sie uns davon ausgehen, dass diese implented in der "out-parameter" Weg. Hätte ich code schreiben, nur um die SafeFileName:

    string dummyFileName;
string[] dummyFileNames;
string safeFileName;
string[] dummySafeFileNames;

myDialog.ShowDialog(out dummyFileName, out dummyFileNames, out safeFileName, out dummySafeFileNames);
    • Ich kann nicht behaupten, dass mit. Dies sieht schrecklich.
    • Sicher, netter Kontakt 🙂
    InformationsquelleAutor Serhat Ozgel
  3. 2

    Ich persönlich versuchen zu vermeiden, out-Parameter, wo immer möglich, obwohl ich verstehe, dass wie die GoTo-Sie sind manchmal ein notwendiges übel. Ich würde sagen, dass es viel besser wäre, verwenden Sie die Eigenschaften oder Methoden, um die Informationen zurückgeben.

    InformationsquelleAutor Calanus
  4. 2

    In meiner Erfahrung, eine benutzerdefinierte modalen dialog, der sammelt nur eine information ist eine ziemlich extreme Ausreißer. Viel häufiger sind null und viele.

    Dialog und sammelt viele Stücke von Daten, ist es fast sicher geändert werden, an einem gewissen Punkt zu sammeln, nur einer mehr. Ich würde viel lieber fix nur der code, der verwendet, dass ein neues Stück von Daten als jedes einzelne Stück code, der verwendet einen modifizierten dialog.

    Auch darüber nachdenken, wie ein Entwickler verwendet IntelliSense, um Ihre Klasse. Er geht, um zu geben diese:

    MyDialog d = new MyDialog();
d.ShowDialog(

    ...und bei diesem letzten Tastendruck, IntelliSense erscheint, sagen Sie ihm, dass er jetzt hat, zu erklären, drei neue string-Variablen zur Aufnahme der out-Parameter. Also er bewegt den cursor nach oben, und beginnt zu schreiben:

    string foo;
string

    ...und, wie war der name des zweiten Parameters wieder? Also, zurück nach unten auf die offene Klammer, drücken Sie STRG+LEERTASTE, oh ja, es ist bar, zurück in die Vorherige Zeile, etc.

    Das problem bei der Verwendung von Eigenschaften, die auf einem benutzerdefinierten Dialogfeld ist, dass die Form-Klasse verfügt bereits über eine Millionen Eigenschaften, und die drei oder vier besonderen, die Sie erstellen, gehen verloren in der Mischung. Um dies zu beheben, erstellen einer Klasse für das Dialogfeld Parameter und eine Parameters Eigenschaft dieses Typs auf das benutzerdefinierte Dialogfeld. Das macht den code einfach zu schreiben:

    MyDialog d = new MyDialog();
d.Parameters.Foo = "foo";
d.Parameters.Bar = "bar";
d.Parameters.Baz = "baz";

    da die Namen der parameter pop-up in IntelliSense, und Sie brauchen nicht zu deklarieren jede Variable, die halten Ihre Werte.

    • Alles gute Punkte, vielen Dank. Einer der Gründe, warum ich C# (angefangen habe ich mit VB3) und OOP im Allgemeinen ist, dass ich etwas ändern kann und verlassen sich dann auf die Sprache und die IDE, mich zu zwingen, befassen sich mit ändern, dass im gesamten Programm. Die mehrere Eigenschaften Ansatz ist es nicht, gib mir.
    • Die Intellisense und zu erklären, eine oder mehrere Variablen werden vor dem Aufruf von ShowDialog sind ausreichend, ein problem, dass ich wahrscheinlich nicht bei der Arbeit. Ich hatte gehofft, dass eine der Antworten auf meine Frage wäre, einige Weg von der Deklaration der Parameter in-line.
    • Für eine Sekunde dachte ich, dass ich zurückkehren konnte, eine benutzerdefinierte Parameter-Objekt anstelle eines Strings in meinem Beispiel, und ich möchte nur noch deklarieren Sie eine variable vor dem Aufruf von ShowDialog. Aber der Anrufer würde dann gerne ignorieren, die neu hinzugekommenen Felder.
    • Also ich denke, die Erklärung der einzelnen parameter ist unumgänglich, da der Vorteil ich behaupte, dass für diesen Ansatz.
    InformationsquelleAutor Robert Rossney
  5. 2

    Mein Ansatz ist in der Regel schreiben Sie eine Methode, die intern ShowDialog Aufrufe, dann formatiert die Ausgabe von Daten entsprechend. Für die (ausgedachte) Beispiel:

    public string GetFolderName(){
    if(this.ShowDialog() == DialogResult.OK) {
        return this.FolderName.Text;
    }
    return String.Empty;
}

    In den meisten Fällen kann ich diese Methode statisch ist, und instanziieren der dialog selbst von innerhalb des Körpers von der Methode - so dass der Anrufer nicht zu tun haben mit der form verweist oder die Vorstellung von zur Wahl mit dem 'show' - Methode aufrufen.

    In der non-edge-Fällen mit mehreren output-Werte, die ich in der Regel bauen eine Struktur, die Sie hält diese Werte, dann haben meine " Get " - Funktion zurück, die struct.

    public struct FolderData {
    public static FolderData Empty = new FolderData();

    public string FolderName {get; set;}
    public int FilesInFolder {get; set;}
}

public FolderData GetFolderData(){
    if(this.ShowDialog() == DialogResult.OK) {
        return new FolderData {
            FolderName = this.FolderName.Text;
            FilesInFolder = int.Parse(this.FilesInFolder.Text);
        }
    }
    return FolderData.Empty;
}
    InformationsquelleAutor Erik Forbes
  6. 1

    Ich bevorzuge diese ein, weil ich nicht wie den Ansatz zu bekommen, ergeben sich aus einer Eigenschaft oder einer Methode nach, die Sie getan haben mit der Klasse. Nach dem dialog-Formular gezeigt wurde geschlossen und ich denke, das Objekt sollte nicht mehr verwendet werden, weil logischerweise die Sie getan haben mit dem dialog, warum sollte ich dann verwenden, seine Eigenschaft oder Methode um das Ergebnis zu erhalten?

    • Gut, wenn Sie sehen, der mit(...) entweder mit sich oder Eigenschaft, die es noch im Speicher ist, nach der wenn-so können Sie es verwenden. Also dein letzter Satz ist gut, aber nicht mit dem Beispiel von der Frage.
    • Es könnte sein, in der Erinnerung, dass ist nicht das problem. Ich bin in der Logik dieser, und ich denke, entweder ist es in der Erinnerung, es ist schön, nicht verwendet werden.
    • Sie sind logisch nicht fertig mit dem dialog. Es ist nur nicht mehr auf dem Bildschirm angezeigt.
    • Verdienen Sie den check für den Start alles. 🙂
    • Wie die anderen Robert zeigt, wird der dialog ist nicht verschwunden, nur verborgen. Ich würde nicht sagen, mit einem out-parameter in diesem Fall eine "best-practice" - da sonst niemand befürwortet es oder denkt es ist eine gute Idee.
    • Aber können Sie mir sagen, ein Fall, der Ihnen zeigen wird, schließen, und zeigen Sie das Dialogfeld programmgesteuert und das ist nicht ein Problem des Designs?
    • Ich verstehe nicht deinen Einwand auf das Abfragen der dialog nach hat es sich versteckt (es ist nicht verschwunden). Ich glaube, Sie brauchen, zu erarbeiten, warum Sie denken, es ist ein Problem mit einigen code, der veranschaulicht das Problem.

    InformationsquelleAutor Ali Ersöz
  7. 1

    @Musigenesis, Sie wirklich nicht wollen, zu zwingen, der client-code zu brechen, wenn Sie ändern Sie Ihren dialog, und mit einem out-parameter, der nur manchmal gültig, ist kein gutes design. Wie @Daok sagt, wenn Sie mehr als 1 Wert, der zurückgegeben wird beginnt diese zu erhalten, chaotisch und hässlich schnell.

    Kann man auch nicht erzwingen, dass der client-code zu verwenden das Ergebnis mehr als das .net framework stellt sicher, dass Sie rufen Sie die Eigenschaften auf ein Datei-dialog. Du bist auch nicht, daß der Anrufer etwas zu tun mit der out-parameter, alle, die Sie haben Sie gezwungen, Sie zu akzeptieren eine variable, die Sie möglicherweise nicht verwenden wollen.

    Wenn der dialog ist sehr allgemein kann dies nicht anwendbar sein, aber statt die Ausdehnung aller Arten von Eigenschaften, um das Dialogfeld selbst, eine einzelne Methode, die Sie verwenden konsequent in Ihrer Anwendung, und haben, die eine bestimmte Klasse enthält die relevanten Daten.

    public sealed class MySaveDialogResult
{
    public static MySaveDialogResult NonOkResult(); //Null Object pattern
    public MySaveDialogResult( string filePath ) { ... }

    //encapsulate the dialog result
    public DialogResult DialogResult { get; private set; } 
    //some property that was set in the dialog
    public string FilePath { get; private set; }
    //another property set in the dialog
    public bool AllowOVerwrite { get; private set; }
}

    und Ihr dialog ist

    public MySaveDialog ...
{
    public MySaveDialogResult GetDialogResult() { .... }
}

    Die Essenz ist eine kleine, unveränderliche utility-Klasse, die implementiert auch null-Objekt-pattern. Das null-Objekt wird zurückgegeben, wenn der dialog Ergebnis war nicht OK. Offensichtlich ist die oben ist ein Schuss im Dunkeln für Ihre Bedürfnisse, so ändern Sie es am Willen, machen Vererbung Hierarchien, etc.

    Der wichtigste Punkt ist GetDialogResult(), eine einzige Methode auf dem Dialogfeld, um die Rückgabe einer Klasse kapselt alle relevanten dialog-Daten.

    edit:

    @yapiskan fragt sich, warum nicht einfach 'out' der MyDialogResult versus Berufung GetDialogResult().

    IMO - Die Punkte sind ganz einfach:

    1. Das ist nicht die Konvention
    2. Ein Methodenaufruf ist trivial einfach, und erleichtert, wenn Sie Folgen Sie der "Konvent" - argument wie oben.
    3. out ist umständlich zu bedienen. GetDialogResult() ist nicht, daß der Anrufer zu schreiben, umständlich-code, und es nicht zwingen den Nutzer zum konsumieren der dialog, Ergebnis an der Stelle der Berufung auf den dialog.
    4. Normalerweise das Dialogfeld nicht erneut instanziiert oder re-gezeigt, um das Ergebnis zu erhalten, es ist bereits da. Show() und Hide (), die genau das tun.

    Die Realität ist, du bist trading einen Methodenaufruf für eine peinliche ShowDialog () - syntax. Methodenaufrufe sind Billig, und Sie können nicht garantieren, dass der Aufrufer verwenden Sie Ihre out-parameter mehr, als Sie können dafür garantieren, rufen Sie GetDialogResult(). Warum also die Mühe. Um die Sache einfach zu verwenden, oder nicht überlasten ShowDialog in den ersten Platz.

    Vielleicht, was auch immer Sie sind sub-classing ist funky und Handlungen unterschiedlich und es ist nicht auf Ihre situation zutrifft, aber allgemeiner design-Formen gehen nicht Weg, wenn Sie auf OK klicken, gehen Sie Weg, wenn Sie Entsorgt() von.

    • Alles gute Punkte, vielen Dank. Ich Stimme vollkommen mit dem letzten Punkt, möchte ich eine einzelne Methode, die auf den dialog, gibt alle relevanten Daten. Ich arbeite meistens allein, und normalerweise würde ich hinzufügen, eine Methode GetData() oder was auch immer, um den dialog und nutzen, kein problem. {mehr ...}
    • Aber die Arbeit in einer Gruppe vor kurzem habe ich mehr und mehr bewusst das problem, das hinzufügen von Sachen, Klassen und Formulare, die von anderen Entwicklern nie erkennen, gibt es. Die Idee der Zusammenlegung der GetData-Ansatz mit ShowDialog überlastung gefiel mir, weil andere Entwickler zur Interaktion mit ...
    • ... der dialog, der Weg (da gäbe es keinen anderen Weg, um an seiner internen Daten). Ich weiß es nicht. Es ist schwer, zu bleiben aufgeregt über die Idee, wenn jeder andere hasst es. 🙂
    • Nun, in aller Ehrlichkeit, zwingen code zu brechen, nur pisst Leute Weg. Es ist besser, E-Mails senden, etc. Sie kann Sie nur ermutigen Menschen. Zumindest mit einer einzelnen Daten-Methode der Datenerhebung, der bekommt alle relevanten dialog data gibt es weniger Wahrscheinlichkeit von Ihnen fehlen die Bäume für den Wald.
    • Das idiom ist zu schaffen Konventionen und Ihnen zu Folgen. Es ist in der gleichen Ader wie Spolsky 's" Making Wrong Code Look Wrong'. Wenn Sie Folgen Konventionen, die Sie machen es einfacher, das Programm gegen Sie. Das nicht alles auf einmal passieren, aber passiert in code-reviews und Diskussionen.
    • Ich Frage mich nur, wenn Sie denken, dass der eine gekapselte Klasse wie "MySaveDialogResult" und es ist eine Methode, die zurückgibt, die das Ergebnis "MySaveDialogResult" warum glauben Sie nicht, Sie zu kombinieren in einem ShowDialog-Methode bekommt einen parameter typisiert als "MySaveDialogResult" statt...
    • ... der Aufruf der zwei verschiedene Methoden, wie Sie die ShowDialog-und GetMySaveDialogResult um ein Ergebnis zu bekommen?
    • "Methodenaufrufe sind Billig, und Sie können nicht garantieren, dass der Aufrufer verwenden Sie Ihre out-parameter mehr, als Sie können dafür garantieren, rufen Sie GetDialogResult()". Das ist sicherlich richtig, aber ich kann einfach nicht akzeptieren die Logik des Ladens einer Klasse durch eine Methode und das Ergebnis durch ein anderes. Aber...
    • ...wie @buyutec erwähnt, in .Net Framework, die Dinge sind verschwunden wie die.
    • Sicherlich, aber die Frage war, tagged 'beste Praktiken' so, während wir uns einig, uneinig zu sein als eine Frage des Stils, und Sie sind frei zu schreiben, den code, den Sie schreiben möchten, die 'best-practice' ist das follow-convention 🙂

    InformationsquelleAutor Robert Paulson
Schreibe einen Kommentar