Software Architektur - Keine statischen Klassen 

Ich lege noch einen drauf mit "GlobalHelperUtils" - habe ich auch schon gesehen :)

@@DavidTielke Und XmlHelper (drei Varianten, alle partial), CsvHelper (I'm Prinzip ein selbst gebautes Split), MessageBoxHelper, MailHelper, DateTimeHelper, ... Das ganze Projekt besteht aus so Dingen :D

Vollkommen richtig, Marcus! Wenn ich der "Schubser" war, freut es mich natürlich umso mehr :) Gruß David

Hmmmm, wenn ich das richtige verstanden habe? Also ich habe da dann immer ein Entity verwendet, wenn die Parameter aus der Datenbank kommen. Dieses kann man gut über das Repository Pattern mocken. Warum sollte ich hier den Umweg über eine statische Klasse machen? Gruß Marcus

Hey Jan Hendrik, meine Abneigung gegen statische Elemente hat ja zwei Hauptgründe: 1. Nicht mehr auflösbare Abhängigkeiten zu Logik 2. Nicht mehr auflösbare Abhängigkeiten zwischen Komponentne Wenn Du eine statische Klasse verwendest, um dort String-Konstanten zu bündeln, ist das erstmal ein guter Ansatz weil dadurch entsteht ja keine Abhängigkeit zu einer Logik die du entkoppeln müsstest ABER wenn du diese String-Konstanten in mehreren Komponenten verwendest, hast Du halt auch eine Implementierungsabhängigkeit zwischen den Assemblies und das ist halt mega doof. An der Stelle musst Du dich als Architekt fragen was jetzt das kleinere Übel ist, duplizierte Konstanten in den Komponenten oder die Abhängigkeit zwischen Assemblies - ersteres verschlechtert nur die Wartbarkeit, während letzteres fast alle qualitativen Aspekte zerstört, daher verwende ich solche static-String-Klassen maximial in einer Komponente, aber nicht darüber hinaus. Auch wenn Du kein #FragDavid dran gemacht hast, gucke ich mal, dass wir dazu heute Nachmittag in der Kaffeepause ein kurzes Video machen, weil diese Frage kommt sehr oft :) Danke für den Input! Gruß David

Ich persönlich sehe da zwei Wege: 1. das, was @Marcus Reinicke schreibt: Wenn die String/String-Werte z.B. Name/Wert-Paare sind und die Namen fix vorgegeben sind, dann kann ich sie auch auf Properties mappen. Das Laden und Mappen wiederum lässt sich dann ganz hervorragend mit dem Repository-Pattern im Rest der Anwendung anbieten, das Mapping könnte auch noch eine eigene Abstraktion sein, wenn man das getrennt vom Repository behandeln möchte/muss. 2. eine Art Mapping auf ein Enum oder eine Factory, die anhand der Namen fertige Objekte/Werte zurück gibt. Beides lässt sich ganz hervorragend abstrahieren, also z.B. IMyAbcFactory, die den Namen aus der DB entgegen nimmt. Dann hast Du wieder eine zentrale Stelle, wo deine Konstanten im Code stehen und kannst sie auch tauschen. Konstanten könnten nämlich genauso eine Gefahr sein, auch wenn es nicht ganz so oft vorkommt.

In so einem Fall würde ich auf Extension-Methods zurückgreifen. Ich habe aber auch selber gemerkt: Aus diesen "wirklich fehlenden Funktionen" werden ziemlich schnell immer mehr, das Risiko, es zu übertreiben ist also groß. Davids fixe Regel "kein static" halte ich für zu kurz gedacht, aber in 99% der Fälle korrekt und daher allgemein sicherer, denn nicht jeder achtet so genau auf seinen Code.

Hallo Lars, die alternative ist dir eine ICollectionExtensions per Konstruktor injizieren zu lassen und dann dort diese Methode aufzurufen. Das ist im Code natürlich nicht so lesbar, wie die Lösung mit Extension-Methoden, allerdings funktional vollkommen identisch. Am Ende ist Architektur immer das abwiegen von Entscheidungen: Willst du die bessere Lesbarkeit aber dafür die Wiederverwendbarkeit, Austauschbarkeit und Testbarkeit zerstören? Oder willst du die etwas weniger lesbare Variante mit ICollectionExtensions und dafür weiterhin alle anderen qualitativen Aspekte erfüllen? Ich würde da komplett zu letzterem tendieren!!! Zusätzlich finde ich den Hinweis von Paladin007 sehr wertvoll: Einmal so eine Erweiterungsklasse geschrieben, stehen allen Projektbeteiligungen Tür und Tor offen das ganze sehr unvorteilhaft zu "missbrauchen" und meine Erfahrung zeigt das leider auch genau das gemacht wird! Gruß David

Nein, ich würde weiterhin die Finger von Erweiterungsmethoden lassen (siehe meine andere Antwort) weil hier die Lesbarkeit des Quellcodes nicht über die Aspekte wie Wiederverwendbarkeit und Austauschbarkeit auf Komponentenebene gestellt werden sollte und die würde man hier zerstören. Trotzdem Dein Hinweis auf das "übertreiben" teile ich zu 100%, das ist ein weiterer Punkt weshalb ich Erweiterungsmethoden nicht mag :) Danke für die Anmerkung!

​ @David Tielke Bei Erweiterungsmethoden ist die Wiederverwendbarkeit ja genauso gegeben, wie bei einem ICollectionExtensions-Service, Austauschbarkeit natürlich nicht. Aber Beispiel Add vs. AddRange, das ICollection-Interface hat kein AddRange. Das sähe so aus: public static void AddRange(this ICollection collection, IEnumerable items) { foreach (var item in items) collection.Add(item); } Willst Du dafür UnitTests schreiben? Klar, kann man machen, aber das wäre für mich ein Fall von "übers Ziel hinaus geschossen", wo der Aufwand wiederum über den Nutzen liegt. Natürlich besteht dabei die Gefahr, dass solche Extensions auch über's Ziel hinaus schießen und zu viel werden, deshalb sollte man (oder jemand) einen Blick darauf haben. Und ja, das setzt alles voraus, dass alle Beteiligten auf einem Level sind. Meine Denkweise ist eher die, dass ich beim (utopischen) Optimum beginne und das dann den spezifischen Gegebenheiten anpasse oder ggf. umwerfe. Wenn z.B. ein einziges Teammitglied ein Berufseinsteiger ist, alle anderen aber top fit sind, dann bekommt der Eine ein Verbot verpasst, die Extensionmethods anzufassen. Wenn es umgekehrt ist (einer hat was drauf, der Rest nicht), dann werden Extensionmethods verboten. Aber wir können bei so einer theoretischen Diskussion nicht alle Eventualitäten der verschiedenen Teams betrachten. Ich habe deshalb auch ein striktes LINQ-Verbot aufgedrückt bekommen: Die Anderen kennen es nicht und könnten es beim Code kopieren (allein das tut weh) falsch nutzen.

Mal ganz naiv gefragt: Was würde gegen eine Klasse ObservableRangeCollection sprechen, welche von ObservableCollection erbt und die ursprüngliche Collection um deine geforderten Methoden erweitert?