Die Größe einer Get-Methode

Question

Gibt es irgendwelche Richtlinien oder allgemeinen Konsens in Bezug auf die Größe eines "Get" in Bezug auf Zeilen des Codes? Ich habe eine Get-Methode für ein Mitglied, das hier ganz leicht auf 30 Zeilen Code angewachsen ist. Ich bin mir nicht sicher, an welchem ​​Punkt dies in eine Methode herausgezogen werden sollte. Aber dann würde ich es nur etwas wie GetMyString nennen und den Wert einem anderen Mitglied zuweisen und es trotzdem im Konstruktor aufrufen.

Ist es jemals das wert?

Ist das für SO zu subjektiv?

Answer 1

Antwort des dcastro ist gut, aber einige Expansion nutzen könnten:

• es dauert nicht lange

nicht quantifizierbare ist zurückzukehren; Lassen Sie uns das quantifizieren. Eine Eigenschaft sollte nicht mehr als, sagen wir, zehnmal länger dauern, als ein Feld zu holen.

• es keine Verbindung zu externen Ressourcen (Datenbanken, Dienstleistungen, etc.)

Diejenigen langsam sind und so typischerweise unter der ersten Regel fallen, aber es ist ein zweiter Aspekt dazu: Scheitern sollte selten oder unmöglich sein. Property-Getter sollten keine Ausnahmen auslösen.

• es hat keine Nebenwirkungen

ich das beobachtbaren Nebenwirkungen klären würde. Eigenschaftsgetter haben oft den Nebeneffekt, dass sie die Eigenschaft einmal berechnen und für später speichern, aber das ist kein beobachtbarer Nebeneffekt.

Nicht nur ist es philosophisch schlecht, dass eine Eigenschaft eine beobachtbare Nebenwirkung hat, es kann auch Ihre Debugging-Erfahrung durcheinander bringen. Denken Sie daran, wenn Sie sich ein Objekt im Debugger standardmäßig ansehen, ruft der Debugger seine Eigenschaften-Getter automatisch auf und zeigt die Ergebnisse an. Wenn dies langsam ist, verlangsamt dies das Debugging. Wenn dies fehlschlägt, wird die Debug-Erfahrung mit Fehlermeldungen gefüllt. Und wenn dies einen Nebeneffekt hat, dann ändert das Debuggen des Programms die Funktionsweise des Programms, was es sehr schwierig macht, den Fehler zu finden. Sie können natürlich die automatische Eigenschaftsbewertung deaktivieren, aber es ist besser, zuerst gute Eigenschaften zu entwerfen.

Answer 2

Dies ist eine häufige schlechte Praxis, um eine ganze Reihe von Zeilen in eine Get-Methode zu schieben. Ich habe etwas im Visual Studio namens CodeMaid installiert. Es hat etwas, das CodeMaid Spade genannt wird, das jede Methode bewertet und Ihnen eine Kerbe gibt. Je höher der Wert, desto schlechter ist Ihre Methode. Es kann auf Eigenschaften auch verwendet werden. Ich schlage vor, Sie versuchen es, es hilft bei der Formatierung, Einrückung und eine Reihe anderer guter Praktiken sowie

Answer 3

Es ist nicht wirklich die Größe, die zählt (kein Wortspiel beabsichtigt). Es ist in Ordnung, Ihre Logik in einem Getter zu haben, solange

• es nicht lange dauern,
• es auf externe Ressourcen (Datenbanken, Dienste, etc.) keine Verbindung zurück
• es doesn keine Nebenwirkungen

Dies sind nur einige der Richtlinien für die ordnungsgemäße Verwendung von Eigentum.

bearbeiten

Die oben genannten Richtlinien teilen sich ein ideal: Eigenschaftenaccessoren wie Datenzugriff verhalten sollten, denn das ist, was die Nutzer erwarten.

Aus dem Buch Effective C# von Bill Wagner:

Eigenschaften sind Methoden, die von dem anrufenden Code wie Daten betrachtet werden können. Das bringt einige Erwartungen in die Köpfe Ihrer Nutzer. Sie sehen eine Eigenschaft Zugriff als ob es ein Datenzugriff war. Immerhin , so sieht es aus. Ihr Eigentum Accessoren sollten diese Erwartungen bis zu erfüllen. Get Accessors sollten keine beobachtbaren Effekte haben. Set-Accessoren ändern den Status und Benutzer sollten diese Änderungen sehen können.

Eigenschaften Accessoren haben auch die Leistung Erwartungen für Ihre Benutzer. Ein Eigenschaftenzugriff sieht wie ein Datenfeld Zugriff aus. Es sollte keine Leistungsmerkmale haben, die sich von wesentlich von einem einfachen Datenzugriff unterscheiden.

Eigenschaftenaccessoren nicht lange Berechnungen durchführen sollte, oder machen anwendungsübergreifende Anrufe (wie Datenbankabfragen durchführen), oder tun andere langwierige Operationen, die mit den Erwartungen der Nutzer für eine Eigenschaftenaccessor unvereinbar wäre.

Bonus von Alberto: http://msdn.microsoft.com/en-us/library/vstudio/ms229054%28v=vs.100%29.aspx

Answer 4

Als allgemeine Richtlinie wird ein Verfahren sollte nicht mehr Linien als fit auf einem Bildschirm. Wenn Sie scrollen müssen, ist es zu groß. Teilen Sie es in kleinere Methoden auf.

Answer 5

Es ist nicht unbedingt schlecht, aber wenn ich es wäre würde es mich nervös machen und ich würde versuchen es irgendwie zu versuchen. Ein Getter ist eine Methode, so einfach das Ganze in eine 30+ Linienmethode zu ziehen, wäre meiner Meinung nach Zeitverschwendung. Ich würde versuchen, es zu zerhacken. Z.B. wenn es eine Schleife mit einigen Überprüfungen war, Extrahieren der Überprüfungen als Methoden oder ähnliches.