Ich habe mir Code angesehen, den ich geerbt habe, und ich konnte nicht entscheiden, ob ich ein bisschen Code mag.
Grundsätzlich gibt es eine Methode, die wie folgt aussieht:
%Vor%Es gibt true zurück, wenn es erfolgreich verbindet, andernfalls false.
Ich habe in der Vergangenheit einen Code wie diesen geschrieben, aber jetzt, wenn ich diese Methode sehe, mag ich sie aus verschiedenen Gründen nicht.
Es ist einfach, Code zu schreiben, der einfach den zurückgegebenen Wert ignoriert oder nicht realisiert, dass er einen Wert zurückgibt.
Es gibt keine Möglichkeit, eine Fehlermeldung zurückzugeben.
Das Überprüfen der Rückgabe der Methode sieht nicht wirklich gut aus:
if (! Connect (...)) {....}
Ich könnte Code schreiben, um eine Ausnahme auszulösen, wenn es nicht erfolgreich verbindet, aber ich halte das nicht für eine Ausnahmesituation. Stattdessen denke ich daran, den Code wie folgt zu refactoring:
%Vor%Ich mag, dass andere Entwickler die Erfolgs- und Fehlerzeichenfolgen bereitstellen müssen, damit sie wissen, dass die Methode Fehlerbedingungen hat und ich eine Nachricht zurückgeben kann
Hat jemand irgendwelche Gedanken dazu?
Danke -Matt
Ich habe nur eine Meinung, also nimm es für was es wert ist.
Eine Methode wie "Connect" ist eine Bestellung. Es ist, als würde man es einem Soldaten geben, "Jump" oder "Shoot". Sie erwarten nicht, dass sich der Soldat meldet, es sei denn, er kann die Bestellung nicht abschließen, und das wäre ein seltenes Ereignis.
Als solche habe ich die Tendenz, für solche Methoden keinen Rückgabewert zu haben, aber wenn die Wahrscheinlichkeit besteht, dass bei regelmäßiger Verwendung der Methode Fehler auftreten, dann erstelle ich eine zweite Methode namens TryXYZ, die zurückkehrt ein bool, und wenn nötig, liefert er mir die Ergebnisse von was auch immer XYZ als out-Parameter.
Dies folgt dem Standard, der von den Parse-Methoden verschiedener numerischer Typen in .NET BCL angegeben wird.
In Ihrem Fall hätte ich wahrscheinlich:
%Vor%Wenn Sie die TryConnect-Methode richtig erstellen, wird Connect sehr einfach.
Beispiel:
%Vor%Ich erwarte nicht, dass meine Befehle nicht vollständig sind, aber in dem Sinne, in dem sie dies tun könnten, möchte ich ausdrücklich darauf eingehen.
Ich würde mich für die Ausnahme gegenüber den out -Parametern entscheiden. Wenn Sie möchten, dass die Verbraucher Ihrer Klasse sich um sie kümmern, sorgen Sie dafür, dass sie sich um die Ausnahme kümmern, oder lassen Sie sie in Ruhe. Wenn Sie die Out-Parameter verwenden, machen Sie ihr Leben einfach unbequemer, wenn sie sich nicht darum kümmern müssen, dass sie Wegwerf-Variablen verwenden. Bedenken Sie auch, dass Sie, wenn Ihre Funktion bereits frei ist, eine brechende Änderung einleiten, wenn Sie die Signatur ändern (anstatt eine zusätzliche Überladung bereitzustellen).
Programmierer erwarten Ausnahmen in Fehlerfällen, insbesondere in Sprachen wie C #. Wir wurden trainiert.
Ich sehe deine Punkte aber meine 2c hinzuzufügen.
Ich bin generell kein Fan von Ausgabeparametern. Wenn Sie mehrere Werte aus einer Funktion zurückgeben müssen, überprüfen Sie, was die Funktion gerade macht. In den meisten Fällen sind mehrere Rückgabewerte ein Zeichen dafür, dass eine Methode zu viel tut. In Ihrem Fall ist es legitim, dass ein komplexer Typ von Ihrer Verbindungsmethode zurückgegeben wird (über einen einfachen booleschen Wert hinaus).
Ich wäre dafür, einen benutzerdefinierten Typ von der Verbindungsmethode zurückzugeben, die alle relevanten Informationen statt mehrerer Ausgabeparameter speichert. Denken Sie an zukünftige Erweiterbarkeit, was, wenn Sie mehr Informationen auf dem Weg hinzufügen müssen. Das Hinzufügen zusätzlicher Ausgabeparameter ist eine wichtige Änderung
Ich stimme auch nicht damit überein, einen Benutzer zu zwingen, Speicherzuweisungen für alle Zustandsdaten bereitzustellen. Es kann Zeiten geben, in denen mir die Erfolgsmeldung egal ist (vielleicht interessiert es mich nur, wenn sie falsch ist). In diesem Fall ist es eine Qual, beide Ausgabeparameter zu bestehen.
Ich stimme jedoch zu, dass die Überprüfung des Rückgabewerts der ursprünglichen Methode nicht ideal ist.
Es macht mir nichts aus, dass die Connect-Funktion einen booleschen Wert zurückgibt und ich bin kein großer Fan von Ausgabeparametern. Wenn die Funktion den Verbindungsstatus nicht zurückgegeben hat, müssten Sie wahrscheinlich (abhängig von Ihrem Stil) eine IsConnected-Funktion / Eigenschaft schreiben, um es jemandem zu ermöglichen, sie zu überprüfen, sodass ein Schritt gespeichert wird.
Lassen Sie die Ausnahme, so weit die Erwartungen gehen, vom aufrufenden Code abgefangen werden, der den Anrufer zur Vorsicht zwingt. :)
Ich stimme zu, dass das Nichtbestehen einer Verbindung (in den meisten Fällen) nicht als Ausnahmesituation angesehen werden sollte. Aber es ist auch nicht schön, den Benutzer zu zwingen, Argumente für die Fehlerkette usw. anzugeben. Andere mögliche Lösungen:
Ich bin mir nicht sicher, ob das besser ist als Ihr Refactoring-Code, aber hoffentlich könnte Ihnen das eine andere Idee geben.
Für meine Projekte erstelle ich eine Methode, die die letzte Fehlermeldung zurückgibt.
%Vor%Auf diese Weise können Sie Folgendes tun:
%Vor%Dies ist vielleicht nicht der beste Weg, aber sollte Ihnen helfen:)
Tags und Links c# coding-style