Wenn ich eine große .NET-Methode habe, möchte ich wissen, ob es sinnvoll ist, sie in mehrere Methoden aufzuteilen oder nicht. Meine Bedenken sind: 1 - Gibt es einen Punkt, der eine Methode erzeugt, wenn sie nur einmal aufgerufen wird? 2 - Wenn ich eine private Methode innerhalb meiner Klasse aufruft, versuche ich, keine Instanzvariablen zu verwenden. Ist das gut oder schlecht? Zum Beispiel:
%Vor%edit: Ersetze globale durch Instanz
1 - Gibt es einen Punkt, der ein erzeugt? Methode, wenn es nur einmal aufgerufen wird?
Ja, es gibt viele Gründe, dies zu tun. Lesbarkeit ist vielleicht das Wichtigste. Wenn Sie eine Methode lesbarer und wartbarer machen können, indem Sie sie auseinander brechen, tun Sie dies auf jeden Fall.
Nach meiner Erfahrung mit dem Refactoring von Legacy-Code, bei dem eine Methode viel zu lang ist, tauchen immer wieder kleine Code-Teile auf. Dies sind normalerweise die besten Orte, um nach Refactoring-Möglichkeiten zu suchen. Das Erstellen separater Methoden für diese Teile kann die Länge einer Methode erheblich verringern und dadurch ihre Lesbarkeit erhöhen.
2 - Wenn ich eine private Methode anrufe aus meiner Klasse versuche ich nicht zu verwenden Instanzvariablen. Ist das gut oder? schlechte Praxis?
Normalerweise können Sie den Umfang einer Variablen um so besser machen, je kleiner Sie sind. Wie du tendiere ich dazu, Parameter so oft wie möglich zu verwenden. Wenn eine Methode nur auf ihre eigenen Parameter verweist, wird es viel einfacher, über die Methode nachzudenken, ihre Richtigkeit zu überprüfen und sie korrekt zu verwenden. (Und wenn eine Methode dies tun kann und keinen Zustand ändern kann, dann kauft das eine Menge von Wartungsvorteilen.)
Wenn der Zweck einer Methode am besten darin besteht, die Felder eines Objekts zu manipulieren, ist das vollkommen akzeptabel und in vielen Fällen nicht veränderbar. Wie Sie jedoch angeben, gilt dies insbesondere für öffentliche Methoden. Beim Refactoring einer großen Methode in kleinere Methoden, werde ich selten, wenn überhaupt, direkt auf Mitgliedsfelder in den neuen Methoden zugreifen. Dies dient hauptsächlich dazu, das Verhalten des Programms einfacher zu erklären.
Stellen Sie beim Refactoring auf diese Weise sicher, dass Sie die neuen Methoden als static markieren, wenn sie nicht auf Felder zugreifen. Dies wird die Absicht explizit machen.
In Bezug auf Ihre erste Frage ist die Reduktion der Komplexität in einer Methode Grund genug, eine große Methode in kleine zu zerlegen. Kleinere Methoden sind viel einfacher zu verstehen als eine einzelne große Methode. Wenn es richtig gemacht wird, indem die Methode in logisch konsistente Arbeitseinheiten zerlegt wird, sind viele kleine Methoden in fast allen Fällen einer einzigen großen Methode vorzuziehen. Die einzigen Bedingungen, unter denen dies möglicherweise nicht der Fall ist, sind Auswirkungen auf Ihre Leistung bis zu dem Punkt, an dem es aus dieser Perspektive nicht mehr akzeptabel ist.
In Bezug auf die zweite Frage verwenden Sie, wie @Jason hervorhebt, Instanzvariablen, die nicht Globals innerhalb Ihrer Klasse sind. Ich würde sagen, welche Praxis bevorzugt wird, hängt vom Kontext der Methode ab. Sicher, wenn die Methode in vielen Kontexten wiederverwendet werden kann, von denen nur einige auf Instanzvariablen operieren, sollte sie parametrisiert werden. Wenn Sie nur die Instanzvariablen verwenden, können Sie sich entscheiden, die Parameter nicht zu verwenden, und später für die Benutzerfreundlichkeit umgestalten, falls dies erforderlich ist.
In C # würde ich auch lieber Eigenschaften für Felder verwenden, um die Eigenschaft von der Methode, die sie verwendet, weiter zu entkoppeln.
Um aus Clean Code (einem ausgezeichneten Buch) zu zitieren, sollte eine Methode nur eine Sache und nur eine Sache tun . Wenn Sie mehrere Dinge in einer Methode machen, bedeutet dies wahrscheinlich, dass Sie diese Logik in eine separate Methode extrahieren müssen. Es macht es viel einfacher, den Code auch zu folgen. Also würde ich sagen
Frage 1: Ja, zerbrich es (Trennung der Bedenken).
Frage 2: Im Allgemeinen halte ich es für eine schlechte Praktik, globale Variablen zu haben, es sei denn, Sie müssen unbedingt . Was die allgemeine Frage betrifft, wie man die private Eigenschaft (Instanzvariable) allein über den öffentlichen Getter verwendet, sehe ich keinen Vorteil darin, den Getter zu verwenden. Betrachten Sie zum Beispiel:
%Vor%versus
%Vor% An einem bestimmten Punkt würden Sie haben , um auf die Instanzvariable zu verweisen, indem Sie this verwenden. Also sehe ich keinen Vorteil. Schließlich befinden Sie sich innerhalb Ihrer Klasse , sodass Sie vollständigen Zugriff auf private Mitglieder haben.
Wenn ein Code nur einmal aufgerufen wird, gibt es wahrscheinlich keinen Grund, die Methode überhaupt erst zu erstellen. JEDOCH, wenn das gesagt wird, wenn es eine private Methode ist und es als eine separate Funktion (eine separate Angelegenheit) verwendet wird, dann könnte es eine gute Idee sein, es zu trennen. Sie möchten dies tun, um zu vermeiden, eine einzige enorme Methode zu haben. Ein Beispiel wäre, wenn ich nur einmal in einem Codeabschnitt suche, möchte ich diese Suche dennoch aufteilen, weil Suche eine separate Funktion ist. (Dies ist ein sehr schlechtes Beispiel. Wenn jemand einen besseren hat, können Sie ihn gerne bearbeiten.
Eine Variable ist nicht wirklich global, es sei denn, sie ist im gesamten System zugänglich. Nachdem dies gesagt wurde, würde ich sehr empfehlen, globale Variablen zu vermeiden, weil es das Debuggen sehr schwierig macht und Code durcharbeitet, da die Variablen einen extrem großen Umfang haben. Stattdessen würde ich mich darauf konzentrieren, mehr lokalisierte Variablen zu haben und die Variablen zu übergeben, die eine Funktion / Methode möglicherweise benötigt, und Daten zurückzugeben, die die aufrufende Funktion erwartet. Auf diese Weise halten Sie Ihre Daten besser lokalisiert und der Code ist einfacher zu lesen und zu verwalten. Dies ist nicht spezifisch für private oder öffentliche Methoden.
Tags und Links language-agnostic methods static-methods refactoring