Dies scheint eine Methode zur Überentwicklung zu sein, die jedes Problem als ein Klassendesignproblem behandelt, jede Klasse als eine vertragliche Schnittstelle betrachtet und Großdesigns, Verbosität, Fragmentierung und die Verbreitung neuer Substantive priorisiert, anstatt auf organisches Wachstum, Lesbarkeit und gesunden Menschenverstand zu setzen.

Ich kann den Wert von Strenge im API-Design an Systemgrenzen sehen, und LSP scheint ein schicker Name für "mach keine seltsamen Dinge" zu sein, aber hat der Rest davon außerhalb von klassenmaximalistischen Sprachen wie Java, C# und C++ irgendeinen Wert?
Was sind die SOLID-Prinzipien in Bezug auf C#? SOLID ist ein Akronym, das fünf Prinzipien der objektorientierten Programmierung und des Designs darstellt, die darauf abzielen, Software wartbarer und skalierbarer zu machen. Diese Prinzipien sind:

Single Responsibility Principle (SRP): Eine Klasse sollte nur einen Grund zur Änderung haben, das heißt, sie sollte nur eine Verantwortung haben.

Open/Closed Principle (OCP): Software-Entitäten sollten für Erweiterungen offen, aber für Modifikationen geschlossen sein.

Liskov Substitution Principle (LSP): Untertypen müssen für ihre Basistypen substituierbar sein.

Interface Segregation Principle (ISP): Erstellen Sie feingranulare Schnittstellen, die spezifisch für den Client sind.

Dependency Inversion Principle (DIP): Hochrangige Module sollten nicht von niedrigrangigen Modulen abhängen. Beide sollten von Abstraktionen abhängen.

Diese Prinzipien können auf C#-Code angewendet werden, um sein Design und seine Wartbarkeit zu verbessern.
Tolle Frage!

Die Antwort lautet ja, aber mit einigen praktischen Einschränkungen.

Es ist immer wichtig zu bedenken, dass diese Rahmenwerke dazu dienen, Codebasen verständlicher, flexibler und wartbarer zu machen. Dadurch wird es für Personen, die am Code arbeiten, einfacher, ihre Arbeit zu erledigen. Es hat maximale Vorteile für Personen, die den ursprünglichen Code nicht geschrieben haben und zur Codebasis beitragen. Daher gelten die Prinzipien im Allgemeinen für die meisten Sprachen, auch solche ohne objektorientierte Funktionen, insbesondere solche, die eine Organisation des Codes in Module, Pakete, Dateien usw. ermöglichen. Folglich muss man Aspekte der SOLID-Prinzipien auswählen, die auf sie zutreffen. Daher ist ein vernünftiger Ansatz wichtig, wie diese Prinzipien angewendet werden.

Die praktische Umsetzung der SOLID-Prinzipien erfordert anfangs zusätzlichen Aufwand, zahlt sich jedoch aus, wenn das Team und die Funktionen in der Codebasis wachsen. Daher profitieren diese Prinzipien größeren Teams und Projekten unabhängig von der Sprache. Überentwicklung tritt auf, wenn die Dividenden, die sich aus der Anwendung dieser Prinzipien innerhalb einer bestimmten Zeit ergeben sollten, aufgrund der Codebasis oder des Teams in dieser Zeit nicht eintreten. Wenn beispielsweise nur eine Person an einer kleinen Codebasis arbeitet, die unwahrscheinlich ist, dass sie wächst, kann die strikte Anwendung der SOLID-Prinzipien zu Überentwicklung führen.

Die Einschränkungen dieses Ansatzes beinhalten die Entscheidung, wie viele der Designprinzipien in neuem Code implementiert werden und wie viel sie über zukünftige Refaktorisierung auf Code angewendet werden. In vielen praktischen Fällen ist es besser, einige der Designentscheidungen zu implementieren, wenn der Bedarf im Rahmen eines Code-Refaktorisierungsprozesses entsteht. Dieser Ansatz hilft, das Bedürfnis nach Implementierung der Prinzipien nach Bedarf und das Schreiben von neuem Code ohne strenge Einschränkungen in Einklang zu bringen.