Whiz-zarD

Na ja, ich arbeite inzwischen seit einigen Jahren als Softwareentwickler und das, was ich schon in einigen Firmen an Code gesehen habe, geht echt unter keine Kuhhaut. Da schreiben selbst Entwickler, die 20+ Jahre Berufserfahrung haben, den allergrößten Mist an Code, den man sich nur vorstellen kann. Da werden Design Patterns auf abstruse Art- und Weisen oder sogar komplett falsch implementiert oder viele haben selbst nach 20 Jahren die Objektorientierung nicht verstanden und schreiben weiterhin spaghetticode wie in alten C-Zeiten. An der Software, wo ich jetzt arbeite, hat man statische Klassen aus Faulheit verwendet. Damit man die Klassen nicht instanziieren braucht, hat man sie statisch gemacht (yeeaah! Man spart sich eine Zeile Code...). Hier wurde Mikro-Optimierung auf die Spitze getrieben und von solchen Klassen gibt es hunderte und diese Klassen sorgen in Unittests immer wieder für Probleme, weil z.B. die Methoden Queries an die Datenbank schicken. Der Unittest ist dann von der Datenbank abhängig. Also testet man im Unittest nicht mehr die Methoden an sich, sondern schon komplexe Programm-Strukturen auf einen Schlag. Das Problem ist nun, dass man von statischen Klassen nicht erben und somit nicht mocken kann. Martin Fowler hatte diesbezüglich mal ein Blog-Eintrag geschrieben. Sein Beispiel ist aber relativ trivial. Stell dir mal vor, du hast im Code hunderte solcher Klassen, die hunderte von Abhängigkeiten besitzen, weil man laufe der Jahren die Klassen immer um weitere Methoden ergänzt hat und die Klassen nun mehrere Tausend Zeilen beinhalten. Ist ja auch so schön einfach, einfach statische Klassen zu erweitern ... Mir persönlich geht es auch eher darum, dass du ein gespürt dafür bekommst, wo die Probleme bei statischen Methoden/Klassen liegen und dass man schon wissen sollte, wann dieses Schlüsselwort angebracht ist und wann nicht. Nur weil man die Syntax versteht, heißt es noch lange nicht, dass man auch sauberen Code schreiben kann und das finde ich viel wichtiger als so manches andere aber das bekommt man von Firmen nicht so richtig beigebracht, weil man lieber aufgrund des Zeitdrucks lieber schmutzigen Code schreibt, der zwar jetzt schnell geschrieben werden kann und somit kostengünstig ist aber spätestens in einem halben Jahr hohe Kosten verursacht, weil der Code unwartbar ist.

Aus eigener Erfahrung gebe ich dir den Rat Die Interop-Schnittstelle nicht zu verwenden! Du handelst dir damit mächtig viele potenzielle Fehler ein. Selbst Microsoft rät von diesem Weg ab. Ein weiteres Problem ist, dass die Architektur ab Excel 2013 sich grundlegend geändert hat, sodass man gar nicht mehr sicher mit der Interop-Schnittstelle arbeiten kann. Früher war es so, dass man immer einen separaten Prozess gestartet hat, über den man arbeiten konnte. Inzwischen wird aber nur ein Prozess gestartet. Führt man also ab Excel 2013 new Excel.Application(); aus, so erhält man intern immer den selben Prozess. Die Properties ActiveSheet oder ActiveWorkbook funktionieren dann nicht mehr korrekt, wenn man nebenbei noch an einer weiteren Excel-Datei arbeitet. Man merkt aber erst beim Speichern, dass da irgendwas schiefgelaufen ist. Darüber hinaus ist auch die Interop-Schnittstelle extrem langsam und während die Excel-Datei erstellt wird, kann man auch die Copy/Paste-Funktion nicht mehr benutzen, weil die Interop-Schnittstelle darüber die Daten nach Excel Transferiert. Wenn du Excel-Dateien erstellen möchtest, dann verwende eine Bibliothek dafür, wie z.B. EPPlus. Das hat auch den Vorteil, dass man von einer Excel-Installation unabhängig ist, da Excel nicht benötigt wird.

Das ist ein sehr schlechtes Beispiel! Das verstößt gegen das Single-Responsibility-Prinzip! Die Mitarbeiter-Klasse hat dann plötzlich zwei Aufgaben: Zum einen repräsentiert es ein Mitarbeiter und zum anderen zählt die Klasse auch noch die Anzahl der Mitarbeiter. Die Mitarbeiter sollten in einem Repository gehalten werden und wir fragen das Repository nach der Anzahl. Schon mal es durchaus vorkommen kann, dass man temporär einen Mitarbeiter erstellen möchte, der aber wiederrum später gelöscht wird. Dadurch kann es zu schlimmen Seiteneffekte kommen, wenn die temporären Mitarbeiter-Klassen gezählt werden. Allgemein sollte man mit static sehr vorsichtig sein. Man sollte wissen, was man da tut. Statische Variablen/Methoden sind schlecht zu mocken, daher sollte man sie zugunsten des Unittests vermeiden. Statische Variablen braucht man echt sehr selten und zwar so selten, dass mir nicht mal ein gescheites Beispiel einfällt. In allen Projekten, die ich inzwischen gesehen habe, wo statische Variablen benutzt worden waren, führten sie irgendwann zu massiven Problemen. Statische Methoden brauche ich eigentlich höchstens nur bei Singletons oder Factory-Methoden. Außerdem gäbe es noch die Möglichkeit Mikro-Optimierungen zu betreiben und zwar wenn ich weiß, wenn eine private Methode unabhängig vom Zustand der Klasse ist, dann deklariere ich sie als private static. Dann wird die Methode nur ein mal im Speicher gehalten. Das Problem mit static ist, wenn sich dahinter Logik verbirgt und ein anderes Ergebnis liefert. Beispiel: DateTime.Now Diese statische Eigenschaft gibt pro Aufruf immer ein neues DateTime zurück. Wenn man nun eine Methode testen möchte, die DateTime.Now aufruft, wird man in Schwierigkeiten kommen, einen gescheiten Unittest zu schreiben, dessen Ergebnis reproduzierbar ist, da DateTime.Now nicht reproduzierbar ist. Man fängt dann also an DateTime irgendwie zu mocken. - Warum sollte sich der Umsatzsteuersatz nie ändern? - Die Matrikelnummer eines Studenten gehört dem Studenten, also darf diese nicht statisch sein! - Eine bestimmte RGB-Farbe wäre eine Konstante. - Pi ist ebenfalls eine Konstante. - Ablauf- und Erstellungsdatum gehören zum Lebensmittel und sind somit nicht statisch! Diese Beispiele sind also allesamt falsch und nicht zur Nachahmung empfohlen!

Hallo, liegen die Daten (mehrzahl von Datum) wirklich als String/(n)varchar in der Datenbank? Das macht doch überhaupt keinen Sinn ... Da die Millisekunden fehlen, wenn sie 0 sind, wenn du ToString() aufrufst, sieht es für mich aus, als würden die Daten in einem spezifischen Date-Format vorliegen. Dann kannst du auch einfach die Methode GetDateTime() aufrufen, was deutlich eleganter ist, da man sich den ganzen String-Kram schenken kann. DateTime zeitstempel = reader.GetDateTime(0); mfg Whiz-zarD PS: Die Zeichen : und . müssen nicht escaped werden.