Der Grund, weshalb ich private statische Methoden mag: Ich weiß sicher, dass die Methode meinen internen Zustand nicht ändert. Das heißt aber auch, dass ich das static sofort entferne, wenn ich dadurch irgendwelche Nachteile habe. Wenn ich also irgendetwas losgekoppeltes habe, was ich nur an einer Stelle private brauche, sich eine eigene Klasse mit Interface und Co nicht lohnt und das sich nicht für irgendwelche Instanz-Informationen interessiert (auch keine Zugriffe), mache ich das immer static. Wenn ich später dann wieder so eine Methode sehe, dann weiß ich: Diese Methode ist unabhängig vom Rest. Wenn man dann immer mehr solche Methoden ergänzt (oder sie sogar public mucht), dann ist das ein gutes Beispiel für Code, den man in eine eigene Klasse ziehen und als Abhängigkeit reinreichen sollte. Wenn man aber Parameter ergänzen muss, weil die Methode mehr Infos braucht, dann fliegt einfach das Static raus.
Hey Paladin, dein Argument für Methoden die den internen Zustand nicht ändern, verstehe ich, ABER: welchen konkreten Vorteil hast du dadurch? Hinsichtlich der Qualität finde ich nicht wirklich etwas, daher würde ich das als Argument nicht zulassen. Eine Methode sollte maximal 20 LOC lang sein und wenn diese den internen Zustand ändert, sehe ich das sofort weil irgendwo auf ein Feld geschrieben wird, was nach allen gängigen Richtlinien mit einem Unterstrich (z.B. _repository) beginnen sollte. "gutes Beispiel für Code, den man in eine eigene Klasse ziehen und als Abhängigkeit reinreichen sollte" - damit beschreibst Du genau das Problem was ich damit habe, wenn Du der Methode einen passenden Namen gegeben hast, solltest Du schon beim Design feststellen, das diese Methode in der Klasse nichts zu suchen hat, sondern in eine eigene Klasse ausgelagert werden sollte, welche dann über den Kontrakt injiziert wird. Wenn nun ein Kollege genau diese Funktionalität sucht, die Du in der Klasse "versteckst", wird er sie an der vorgestellten Stelle nicht finden und sie ein zweites Mal implementieren. Die Strategie private Methoden so lange in Klassen zu belassen, bis sie irgendwo anders gebraucht werden und dann erst extrahiert werden, ist absolut keine gute Idee! Gruß David
@@DavidTielke Beispiel: Ein WinForms-Control, das mehrere CheckedListBoxen enthält. Alle bekommen zwei Listen, eine enthält alle Items, die zweite nur die angehakten Items. Ich habe mir daher eine Methode geschrieben, die diese Listen bekommt und die ebenfalls übergebene ListBox mit angehakten oder nicht angehakten Items füllt. Die Methode ist so wie sie ist unabhängig und kann static sein. Was mache ich nun damit? Eine eigene Klasse mit Interface für eine Methode, die im Wesentlichen aus zwei Schleifen und einem If besteht? Nach dem Prinzip hast Du dann irgendwann 100e solcher Methoden/Klassen und blickst nicht mehr durch, obwohl die eigentlich nur an einer Stelle gebraucht werden Da würde ich dann auf KISS verweisen und sagen: Niemand braucht so einem simplen Service, also warum raus ziehen? Static müsste ich es natürlich nicht machen, aber ich mag es gerne, weil ich dann schon an der Methodendefinition sehen kann, dass sich nichts an Zustand ändert. Und nur private Variablen betrachten reicht auch nicht, es gibt noch mehr Möglichkeiten ;)
Das Benchmark ist leider absolut nichtssagend, weil es den Algorithmus testet, nicht den Methodenaufruf. Ein paar Sachen zusammengefasst: •Statische Methoden sind beinahe so schnell wie Inline Methoden. •Instanzmethoden die von der selben Instanz aufgerufen werden sind nur insignifikant langsamer(wenn überhaupt). •Statische Methoden bleiben schnell auch wenn sie von einer anderen Klasse oder Instanz aufgerufen werden. •Bei virtuellen Methoden und besonders Interfaces haben statische Methoden deutlich die Nase vorn. •Methodenaufrufe sind generell so schnell, dass man sich kaum sorgen machen muss, ausser man arbeitet an Performancekritischen Algorithmen. •Und der wichtigste Punkt: Niemals über die Performance Sorgen machen, bevor es Probleme gibt.
Hallo, das sehe ich leider absolut anders, Ziel war es zu schauen, ob bei einem großen Menge von Methodenaufrufen in einem Business-ähnlichen Kontext ein messbarer Zeitunterschied auftritt. Daher der Algorithmus in den Methoden. Es ging nicht darum den Unterschied zwischen static und non-static zu messen, sondern ob es in einem realitätsnahen Szenario einen messbaren Unterschied gibt und deshalb wird (selbstverständlich) auch der Algorithmus mit gemessen und das Ergebnis zeigt nichts anderes als den zweiten von dir aufgeführten Punkt. Gruß David
@@DavidTielke Aber eine reale Business anwendung hätte statt dem += eine Methode, die dann eben eine Kleinigkeit macht. Die Methode wäre üblicherweise eine pure, funktionale methode und daher ideal für private static. Und wenn man die mini methode dann eben für jedes mal aufruft, dann macht das eben doch einen Unterschied. Das mag bei einer Methode auf der selben Instanz der Klasse vielleicht 10% Unterschied machen, aber sobald sich wer denkt "Hey, wir könnten die Methode ja virtual machen" braucht die Add Methode plötzlich 8x so lang.
4 роки тому+2
die Regeln tun mir in der funktionalen Seele weh ;)
Wäre ein super case für BenchmarkDotNet
Hey Sunny,
kannte ich bis grade nicht, mega Tipp, vielen Dank :)
Gruß David
Der Grund, weshalb ich private statische Methoden mag:
Ich weiß sicher, dass die Methode meinen internen Zustand nicht ändert.
Das heißt aber auch, dass ich das static sofort entferne, wenn ich dadurch irgendwelche Nachteile habe.
Wenn ich also irgendetwas losgekoppeltes habe, was ich nur an einer Stelle private brauche, sich eine eigene Klasse mit Interface und Co nicht lohnt und das sich nicht für irgendwelche Instanz-Informationen interessiert (auch keine Zugriffe), mache ich das immer static. Wenn ich später dann wieder so eine Methode sehe, dann weiß ich: Diese Methode ist unabhängig vom Rest.
Wenn man dann immer mehr solche Methoden ergänzt (oder sie sogar public mucht), dann ist das ein gutes Beispiel für Code, den man in eine eigene Klasse ziehen und als Abhängigkeit reinreichen sollte. Wenn man aber Parameter ergänzen muss, weil die Methode mehr Infos braucht, dann fliegt einfach das Static raus.
Hey Paladin,
dein Argument für Methoden die den internen Zustand nicht ändern, verstehe ich, ABER: welchen konkreten Vorteil hast du dadurch? Hinsichtlich der Qualität finde ich nicht wirklich etwas, daher würde ich das als Argument nicht zulassen. Eine Methode sollte maximal 20 LOC lang sein und wenn diese den internen Zustand ändert, sehe ich das sofort weil irgendwo auf ein Feld geschrieben wird, was nach allen gängigen Richtlinien mit einem Unterstrich (z.B. _repository) beginnen sollte.
"gutes Beispiel für Code, den man in eine eigene Klasse ziehen und als Abhängigkeit reinreichen sollte" - damit beschreibst Du genau das Problem was ich damit habe, wenn Du der Methode einen passenden Namen gegeben hast, solltest Du schon beim Design feststellen, das diese Methode in der Klasse nichts zu suchen hat, sondern in eine eigene Klasse ausgelagert werden sollte, welche dann über den Kontrakt injiziert wird. Wenn nun ein Kollege genau diese Funktionalität sucht, die Du in der Klasse "versteckst", wird er sie an der vorgestellten Stelle nicht finden und sie ein zweites Mal implementieren. Die Strategie private Methoden so lange in Klassen zu belassen, bis sie irgendwo anders gebraucht werden und dann erst extrahiert werden, ist absolut keine gute Idee!
Gruß David
@@DavidTielke Beispiel:
Ein WinForms-Control, das mehrere CheckedListBoxen enthält. Alle bekommen zwei Listen, eine enthält alle Items, die zweite nur die angehakten Items.
Ich habe mir daher eine Methode geschrieben, die diese Listen bekommt und die ebenfalls übergebene ListBox mit angehakten oder nicht angehakten Items füllt.
Die Methode ist so wie sie ist unabhängig und kann static sein.
Was mache ich nun damit? Eine eigene Klasse mit Interface für eine Methode, die im Wesentlichen aus zwei Schleifen und einem If besteht?
Nach dem Prinzip hast Du dann irgendwann 100e solcher Methoden/Klassen und blickst nicht mehr durch, obwohl die eigentlich nur an einer Stelle gebraucht werden
Da würde ich dann auf KISS verweisen und sagen: Niemand braucht so einem simplen Service, also warum raus ziehen?
Static müsste ich es natürlich nicht machen, aber ich mag es gerne, weil ich dann schon an der Methodendefinition sehen kann, dass sich nichts an Zustand ändert.
Und nur private Variablen betrachten reicht auch nicht, es gibt noch mehr Möglichkeiten ;)
Das Benchmark ist leider absolut nichtssagend, weil es den Algorithmus testet, nicht den Methodenaufruf.
Ein paar Sachen zusammengefasst:
•Statische Methoden sind beinahe so schnell wie Inline Methoden.
•Instanzmethoden die von der selben Instanz aufgerufen werden sind nur insignifikant langsamer(wenn überhaupt).
•Statische Methoden bleiben schnell auch wenn sie von einer anderen Klasse oder Instanz aufgerufen werden.
•Bei virtuellen Methoden und besonders Interfaces haben statische Methoden deutlich die Nase vorn.
•Methodenaufrufe sind generell so schnell, dass man sich kaum sorgen machen muss, ausser man arbeitet an Performancekritischen Algorithmen.
•Und der wichtigste Punkt:
Niemals über die Performance Sorgen machen, bevor es Probleme gibt.
Hallo,
das sehe ich leider absolut anders, Ziel war es zu schauen, ob bei einem großen Menge von Methodenaufrufen in einem Business-ähnlichen Kontext ein messbarer Zeitunterschied auftritt. Daher der Algorithmus in den Methoden. Es ging nicht darum den Unterschied zwischen static und non-static zu messen, sondern ob es in einem realitätsnahen Szenario einen messbaren Unterschied gibt und deshalb wird (selbstverständlich) auch der Algorithmus mit gemessen und das Ergebnis zeigt nichts anderes als den zweiten von dir aufgeführten Punkt.
Gruß David
@@DavidTielke Aber eine reale Business anwendung hätte statt dem += eine Methode, die dann eben eine Kleinigkeit macht. Die Methode wäre üblicherweise eine pure, funktionale methode und daher ideal für private static.
Und wenn man die mini methode dann eben für jedes mal aufruft, dann macht das eben doch einen Unterschied.
Das mag bei einer Methode auf der selben Instanz der Klasse vielleicht 10% Unterschied machen, aber sobald sich wer denkt "Hey, wir könnten die Methode ja virtual machen" braucht die Add Methode plötzlich 8x so lang.
die Regeln tun mir in der funktionalen Seele weh ;)
Solche Gedanken sind freilich nicht auf alle Programmierparadigmen übertragbar ;)