Angewohnheit von Codierung mit einer Methode und Codierung mit mehreren Methoden

Wenn man über Programmierung nachdenkt, gibt es viele verschiedene Arten von Gewohnheiten und Stilen hinsichtlich der Organisation und Definition von Methoden und deren Strukturierung. Aber wenn sie komplexer werden, werden sie oft so umfangreich, dass sie entweder Abschnitte wiederholen, die ziemlich komplex und umfangreich sind, oder sie tun Dinge, die nicht unbedingt innerhalb dieser speziellen Methode benötigt werden und extrahiert und vielleicht sogar in anderen Methoden verwendet werden könnten, wodurch mehr als notwendige Codewiederholungen vermieden werden. Natürlich fällt dies eher unter Optimierung als unter erzwungene Notwendigkeit.

Sehen wir uns nun an, in welchen Fällen die Kodierung in einer einzigen Methode eine gute Kodierungsangewohnheit ist, während sie in anderen Fällen möglicherweise nicht sinnvoll ist.

In dem Beispiel einer utility-Klasse, z.B. einem Dateilader, wäre es einfacher, in der Methode selbst zu prüfen, ob es sich um eine Datei handelt, die bereits existiert, in die geschrieben werden kann, die gelesen werden kann und die geöffnet werden kann und/oder deren Inhalt zurückgegeben werden kann oder in die ein neuer Inhalt geschrieben werden kann. Alles in einer Methode, die wir FileAccess-Methode nennen, klingt logisch und praktisch, wenn man bedenkt, dass die übergebenen Parameter den Pfadnamen, ein boolean Argument, das definiert, ob es sich um eine Lese- oder Schreibdatei handelt, eine Zeichenkette oder mehrere und einen neuen Wert, der in die Datei geschrieben werden soll oder, falls er weggelassen wird, nicht berücksichtigt wird, umfassen. Ein Java-Beispiel wäre:

public String[] fileAcess(String pathName, boolean schreiben, String… werte){}

Da es sich um eine mehrfache Methode zum Schreiben und Lesen handelt, die null zurückgibt, wenn sie schreibt oder kein Inhalt in der besagten Datei vorhanden ist, sowie null zurückgibt, wenn die Methode auf einen Fehler gestoßen ist, den Inhalt zurückgibt, wenn er vorhanden ist und einen direkten Zugriff verwaltet, der immer gleich funktioniert. Hierfür Codeabschnitte zu extrahieren und daraus mehrere Methoden zu machen, könnte gut sein, wenn man mehr Methoden haben möchte, die einen Teil ihrer Funktionen haben, aber da es sich um eine Methode zum Lesen und Schreiben, Abfangen von Fehlern und Verwalten von Inhalten handelt, müsste sie nicht extrahiert werden und wäre vielleicht besser, einfach im Körper der Methode gehalten zu werden.

Andererseits wäre ein Beispiel für eine Multi-Methodencode-Lösung eine Utility-Klasse für Mathematik. Ein Beispiel wären Berechnungen und Operationen mit Zahlen, mit dem Schwerpunkt auf Primzahlen.

Wenn man alles in eine einzige Methode packt, würde sich das Codemuster der Klasse wiederholen, was kontraproduktiv wäre. Deshalb würde eine Lösung mit mehreren Methoden dem Zweck am besten entsprechen und wäre eine bessere Gewohnheit. Andererseits entscheiden der Zweck und das Ziel darüber, ob es sich lohnt, etwas in mehrere Abschnitte aufzuteilen oder ob es besser ist, es zusammenzuhalten. Bei einer Methode, die eine Zahl nimmt und die nächstgelegene Primzahl zurückgibt, wäre es vielleicht gut zu prüfen, ob die gegebene Zahl nicht schon selbst eine Primzahl ist. Aber auch das könnte eine Methode sein, die sich auf Primzahlen bezieht und mit der man prüfen kann, ob eine Zahl eine Primzahl ist oder nicht. Sowohl die Prüfung als auch das Auffinden der nächstgelegenen Primzahl müssten jedoch die umliegenden Primzahlen berechnen, die in den Bereich der gegebenen Zahl fallen, daher könnte auch dies in einer separaten Methode untergebracht werden, die sowohl von der Prüfung als auch von der Suche verwendet wird. Da beide die Primzahlen ermitteln müssen, aber beide unterschiedlich sind, benötigt der eine die Primzahl unterhalb und oberhalb einer bestimmten Zahl, der andere die Primzahl, die der gegebenen Zahl am nächsten liegt, um festzustellen, ob es sich um dieselbe Zahl handelt oder nicht. Die Lösung ermöglicht es dem Benutzer, drei Methoden zu haben, eine, um die der gegebenen Zahl am nächsten liegende Primzahl zu ermitteln, eine, um die n-te Primzahl zu ermitteln und eine, um zu prüfen, ob die gegebene Zahl eine Primzahl ist oder nicht. Die n-te Primzahl-Methode kann verwendet werden, um eine Primzahl oberhalb oder unterhalb einer bestimmten Zahl zu finden, und wenn sie Ressourcen schonend durchgeführt wird, muss sie nur einmal angewendet werden und verwendet ansonsten zuvor berechnete Zahlen. Damit wäre die Methode selbst umso effektiver und hilfreicher, je mehr sie verwendet wird, da zwei andere Methoden im Grunde auf ihr beruhen. Diese Vielfach-Methoden-Struktur ist weitaus besser, als wenn jede Methode den Code einer anderen dupliziert, während sie auf diese Weise Code von einer zur anderen teilen.

Fazit:

Gut zu wissen ist es, in welcher Anwendung was das genaue Ziel ist, wie auch ob es die Möglichkeit gibt oder geben soll, das etwas dazu kommt oder erweitert wird. Ebenso muss betrachtet werden, ob es nun nötig ist, alles zusammen auf einmal in einer einzigen Methode zu tun, oder ob man es wirklich nicht in einzelne abschnitte teilen sollte, um strukturiert zu bleiben, oder auch sich Code Wiederholungen zu sparen, die nicht unbedingt hätten sein müssen. Somit kann man schwer sagen wo was jetzt besser wäre, weswegen eine Gute Angewohnheit wäre, im Voraus zu wissen oder auch zu planen, Was ist das Ziel, was kann ich heraus geben as teil Produkt und was darf nicht sein, das mir alles kaputt machen kann oder mir die Arbeit nur erschwert. Eine Schlechte Angewohnheit ist, ohne Planung einfach frei nach Schnauze zu arbeiten und am ende nur code Wiederholungen einzubauen oder eine Methode unnötig Komplex aufbauen, wo man selbst einfacher den Überblick verliert als ihn behält. Somit sind das Ziel und den Überblick über den eigenen Code zu behalten das, was einem zeigt sich gute Angewohnheiten zugelegt zu haben anstelle von schlechten Angewohnheiten die einem nur in die quere kommen auf lange Sicht geplant.