Finger weg von static in C#, Java & Co [Mit Beispiel] Clean Code Tipp #12

Im Clean Code Tipp der Woche beantworten wir dieses Mal die Frage: Ist static böse? : Clean Code beschreibt nicht nur die Struktur des Quellcodes in der Programmierung, sondern auch deren Struktur: hier kommt das Schlüsselwort static ins Spiel bzw macht dieses kaputt. Egal ob in C#, Java, Kotlin, Scala, TypeScript oder JavaScript - die nutzung von static bzw globalen Elementen verringert Eure Softwareuqalität und ist damit genua das Gegenteil von Clean Code. Wir schauen uns im Clean Code Tipp der Woche #12 an, warum genau das Schlüsselwort böse ist und wie Du es besser machen kannst.

▬ Über diesen Kanal ▬▬▬▬▬▬▬▬▬▬▬▬

Seit vielen Jahren arbeite ich als Consultant, Coach und Trainer für professionelle Softwareentwicklung mit den Schwerpunkten Softwarequalität, Softwarearchitektur sowie Prozessmanagement. Auf meinem Kanal möchte ich Euch mein Wissen und meine langjährige Erfahrung in diesen Bereichen vermitteln - natürlich kostenlos. Dabei versuche ich stets Euch das Wissen so zu vermitteln, dass Ihr damit direkt in der Praxis loslegen könnt und das ganze immer mit guten Portion Humor. Lernen soll ja schließlich Spaß machen :)

▬ Empfohlene Videos ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Wichtige Links ▬▬▬▬▬▬▬▬▬▬▬▬

▬ Social Media ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

[krccmsitp]

(C#) Ich benutze manchmal statische Klassen, aber die sind prinzipiell zustandslos, d.h. haben ausschliesslich Methoden.

[bootfahrer]

Ich nutze bei kleinen pure functions (Math.Max, Vector3.Normalize), extension methods und Interops static.

[tobiasnickel]

bei minute 4:19 bist du aber ne schoene Abkuerzung gegangen und hast einfach alles durchgestrichen. das wort static aendert garnichts an der lesbarkeit. und gar nichts an der modifizierbarkei. testbar ist der code auch immernoch auch wenn ich zugeben will das es einschraenkungen gibt. und in classe X kann kann der entwickler sich ebenfalls entscheiden eine neue klasse S2 zu nutzen. die abhengigkeit kist dann halt in der klasse definiert und nicht im DI-container oder irrgendwo sonst. und ob das jetzt statisch ist oder nicht, s kann ueberall verwendet werden. was sehe ich falsch?

[paulsalomon]

In meine in Java haben statische Klassen eine andere Bedeutung. Dort gibt es sie nur als innere Klassen und das static sorgt dafür, dass sie auch von außerhalb der Äußeren Klasse nutzbar sind. Oder nicht?

[RealDieselMeister]

Statische Methoden sind wunderbar zum Testen und kommen eine "pure" function aus dem "functional programming" ziemlich nahe. Also nein. Ich sehe das hier anders. Und da C# ja unbedingt mehr "functional" sein muss, kommt man um statische Methoden, die "pure functions" darstellen, nicht herum.

Es gibt einen ganzen Weg, wie man in einem Command/Event Architektur gezielt mit statischen Methoden die Domain-Logik modellieren kann und damit ist sie wunderbar testbar.
Same Input, same Output.

Ich gebe zu, selbst wenn man OOP betreibt, sollte man "pure functions" immer statisch machen!

[medn_]

Statische Klassen (oder generell statische Dinge) versuchen wir grundsätzlich zu vermeiden.

Ab und an werden mal Erweiterungsmethoden verwendet. Aber diese versuchen wir klein und ohne State zu halten. Sodass diese z.B. nur etwas umwandeln, umrechnen, ... (was sich dann auch immer ganz gut testen lässt)

[Thommie-esjx]

was ist denn mit normalen Klassen, aber mit statischen Methoden und statischen Variablen?

[tb]

Wie stehst du dazu Methoden aus Utility-Klassen als static zu deklarieren?

[DJTechnostyler]

Bin ich nicht mit einverstanden. Was ist mit statischen Methoden wie: User.getById(), User.findeOne(), Number.isFloat(), Number.isInt(), u.s.w. Ich denke du verstehst, welche Art von Methoden ich meine. Die müsste man dann alle in einer extra Funktionalität unterbringen, was meine Meinung nach den Code NICHT lesbarer macht. Gerade bei sowas wie Models bin ich eher weniger ein Fan von dem Repository weil sich gerade die getter und query methoden wunderbar generalisieren lassen und somit hervorragend in eine entsprechende Manager-Klasse passen.

ps: Komme aus der JavaScript / TypeScript welt. Da ist ja im Grunde erst mal alles "static"

[ulfdellbrugge]

Ich programmiere viel Javascript und benutze selten klassenbasiertes OOP. Sagt mal, habt ihr viele Klassen, wo beliebig viele Objekte erzeugt werden? Also in einem Spiel wären das wohl einfach eine Reihe von Gegnern die dynamisch in die Welt gepusht werden. Weil es gibt ja auch so einzigartige Entitäten, wo entweder Singletons oder all static Klassen und in meinem Fall plain objects benutzt werden, die in anderen Umgebungen wohl eher Module (golang) genannt werden. Macht ihr in Java und C# dann immer Singletons daraus, um mehrere Instanzen zu unterbinden? Oder wie wird mit so etwas umgegangen?

[beerenmus]

Ich verwende in meinen Spiel eine Klasse Context mit dem Singleton Pattern Design. Darin sind wichtige Attribute wie Keyboard, Mouse, Höhe und Breite des Bildschirm und ganz viele andere Attribute. Sollte ich das Design nochmal überarbeiten?

[andreweinert]

Wir haben einen einzigen Anwendungsfall für statische Klassen. Wir haben die Konvertierung unserer Entities in Datenmodelle in eine statische Klasse ausgelagert. Die statische Klasse ist auch nach außen hin nicht sichtbar und kann somit nur von der eigentlichen Mangerklasse verwerwendet werden.

[sahinvarol]

Hi, danke für das Video. Was ist hier mit Paket im Kontext von C# gemeint? Ein Namespace zb ?

[thomassteinbach]

Nachdem wir auf Quarkus setzen, verwenden wir DI und dann sind das einfach die Klassen mit der Annotation ApplicationScoped. Somit sind etwa 100% der Fälle weg, in denen man auf die Idee kommen könnte, das Schlüsselwort static zu verwenden. Das einzige was übrig bleibt sind Konstanten, die natürlich static sind.

[PeterEichhorn]

Wie ich das so raus höre, scheint es ja grundsätzlich schlecht zu sein "static" einzusetzen. Die Argumente diesbezüglich kann ich auch verstehen. Wie stehst du dann zu ExtensionMethods die gern von Microsoft und anderen bereitgestellt werden und welche Alternativen siehst du da?

[geowody]

Ich verwende gerne Extensions, das geht nicht ohne statische Klassen. Allerdings dürfen die Klassen keinen Status führen.

[DiegoP]

Auf Embedded Systemen mit kleinen Microcontroller (zB Cortex M) würde ich ohne statische Singletons jedes Mal den Flash Speicher sprengen.

Allerdings lassen sich auch statische Singletons durch Dependency Injection und Statischen Interfaces prima entkoppeln, um eben die von dir genannten Attribute zu erreichen, wie Lesbarkeit, Testbarkeit, usw.

Ich finde deine Videos Klasse und hab auch schon viel lernen/auffrischen können.

Manchmal fehlt mir aber etwas der Bezug zum Zielsystem. Manche deiner Aussagen, sind eben manchmal nicht ganz so allgemein gültig. Nicht böse gemeint, aber evtl. könnte diese Information manchmal dem Lernenden Zuschauer weiter helfen.

Oder hast du im Bezug auf Embedded Systemen eine andere Meinung?

Gruß

[fiedelbambu]

meiner Meinung nach : ISt die Verwendung von "static" in C# weder grundsätzlich gut noch schlecht, sondern hängt davon ab, wie und wo es angewendet wird, und welche Anforderungen das Programm hat.

[franke]

@David: du sagst es aber auch selbst, das eine erstellt Objekt bleibt im Speicher und wird immer wieder verwendet bzw. kann immer wieder verwendet werden.
Dadurch, dass der GC für Fragmentierung sorgt, ist es doch gut, dass Objekte länger leben und immer wieder vernwedet werden; auf diese Weise wird Speicherfragmentierung verhindert.
Microsoft selbst schreibt, dass die Heap-Fragmentierung bei lang laufenden Programmen zu problemen führt und somit für mich C# keine Programmiersprache für 24/7 Software (gerade zur Atuomatisierung) ist.

[Humanrebel]

Ich nutze static für zustandslose Erweiterungsmethoden, die auch auf keine weiteren Komponenten zugreifen.
Oder generelle Einsprungspunkte für Injektion von Delegaten, wenn die Instanz, bei der injiziert wird nicht einfach ereeichbar ist. Durch Injektion eines Fakes wird die Testbarkeit gewährleistet.
Oder private Methoden, die auf keine Instanzvariablen zugreifen. Bei letzterem suche ich noch nach einer Alternative.