Werden statische Klassen mit statischen Methoden als SOLID betrachtet?

SOLID enthält das Liskov-Substitutionsprinzip, das den Begriff "Objekte in einem Programm sollten durch Instanzen ihrer Subtypen ersetzt werden können, ohne die Korrektheit dieses Programms zu ändern".

Da statische Klassen mit statischen Methoden (ein bisschen wie die MathKlasse) überhaupt keine Instanzen haben, wird mein System als SOLID betrachtet, wenn ich statische Klassen mit statischen Methoden habe?

language-agnostic solid static-access

— Pacerier
quelle

Ich finde diese Frage großartig. Mal sehen, was die Community zu bieten hat.

— Saeed Neamati

Eine Math-Klasse enthält keinen Status. Sie geben also niemals Gegenstände dieses Typs wirklich weiter. Ich bin mir also nicht sicher, wie das überhaupt relevant ist.

— Martin York

Ich glaube nicht, dass statische Klassen wirklich als SOLID bezeichnet werden können (viel aus den gleichen Gründen, wie bereits erwähnt), aber ich würde sie als einen großartigen Befürworter und Werkzeug für das DRY-Prinzip betrachten.

— Dreza

Wieso das? Nach meiner Erfahrung führt eine Überbeanspruchung statischer Klassen meist dazu, dass sich Menschen die ganze Zeit wiederholen und der halbe Code permanent ein globales statisches Gottobjekt manipuliert.

— back2dos

Ich denke, ich denke mehr über Utility-Klassen nach, um gemeinsamen Code bereitzustellen. Ich bin damit einverstanden, dass sie leicht und häufig missbraucht werden, aber ich denke immer noch, dass sie nützliche Mittel bieten können, um gemeinsamen Code zusammenzufassen, bei dem der Status keine

— Rolle spielt

Antworten:

LSP bezieht sich auf die Übergabe einer Instanz einer Klasse an eine Methode, wobei die Methode einige Aufgaben mit dieser Instanz ausführt und häufig eine Art Ergebnis liefert. Dies spielt für statische Klassen keine Rolle, da Sie in C # keine Instanz einer statischen Klasse erstellen können.

Noch wichtiger ist, dass statische Klassen versiegelt sind und daher nicht vererbt werden können. Damit ist Ihre Frage in C # umstritten.

Sie können sagen, dass statische Klassen immer LSP-kompatibel sind, da Sie niemals eine Unterklasse erstellen können, die gegen dieses Prinzip verstößt. Sie können auch sagen, dass statische Klassen aus demselben Grund niemals LSP-kompatibel sind.

In Java unterscheiden sich statische Klassen geringfügig. Sie können eine Klasse der obersten Ebene nicht als "statisch" markieren. Wenn Sie also eine Dienstprogrammklasse erstellen möchten, die den statischen Klassen von C # ähnelt, müssen Sie sie als deklarieren finalund ihren Konstruktor ausblenden. Sobald Sie dies tun, verhalten sie sich jedoch ähnlich wie in C # - Sie können sie weder instanziieren noch in Unterklassen unterteilen. Sie können eine innere Klasse als deklarieren static, aber das bedeutet nicht dasselbe wie in C #: Es bezeichnet einfach eine verschachtelte Klasse der obersten Ebene .

VB.NET verhält sich in diesem Fall meines Wissens genauso wie C #.

Sie haben nicht erwähnt, ob Sie an den anderen Grundsätzen interessiert sind, aber der Vollständigkeit halber werde ich sie trotzdem einbeziehen.

S ingle Verantwortung Prinzip : eine statische Klasse leicht folgt diesem Prinzip.
O pen / closed-Prinzip : Da statische Klassen versiegelt sind, können sie diesem Prinzip niemals folgen.
L iskov Substitutionsprinzip : wie oben.
I nterface Segregation Prinzip : gilt nicht für eine einzige Klasse, aber Splitting einer große statische Klasse in kleinere, spezialisiertere Richtung nach diesem Prinzip ein Schritt sein könnte.
D Prinzip der Ependenzinversion : Statische Klassen können keine Interfaces implementieren, daher hängt jede Klasse, die sie verwendet, immer von der jeweils vorhandenen Implementierung ab. Statische Klassen verletzen daher dieses Prinzip.

Da statische Klassen nicht alle 5 Kriterien erfüllen, sind sie nicht SOLID.

— Adam Lear
quelle

SOLID zu sein bedeutet, dass wir alle 5 Kriterien erfüllen müssen. Bedeutet das nicht, dass sie nicht SOLID sind?

— Pacerier

@Pacerier Ja, aber man sollte nicht die ganze Zeit versuchen, eine Klasse in SOLID einzuschleusen, wenn sie nicht benötigt wird. es hängt vom Kontext der Klasse ab. Wenn es eine Utility-Klasse oder so ist, ist es in Ordnung, IMO nicht "SOLID" zu sein, aber wenn es eine tatsächliche Domain-Klasse ist, die eine bestimmte Domain-Nutzung hat ...

— Wayne Molina

Ich würde eine solche Klasse nicht als objektorientiert klassifizieren und daher würde ich sagen, dass sie die Prinzipien des objektorientierten Designs nicht erfüllen kann (und sollte).

Diese Klassen sind lediglich eine Problemumgehung für die Unfähigkeit, Code außerhalb einer Klasse in Sprachen wie Java und C # bereitzustellen. Gegebenenfalls sollten sie als eigenständige Funktionen definiert werden, da sie keinen Nutzen aus der Objektorientierung ziehen.

— Gyan alias Gary Buyn
quelle

Ich würde nicht damit einverstanden sein, eigenständige Funktionen außerhalb der Klasse zu platzieren. Die einfache Möglichkeit, verwandte Funktionen (statisch oder nicht) unter einem gemeinsamen Namen zu gruppieren, ist für die Lesbarkeit hilfreich. Mathematische Funktionen passen perfekt zur Rechnung.

— Jojo

@jojo Einverstanden. Sprachen, die Funktionen unterstützen, die außerhalb von Klassen definiert sind, unterstützen auch die logische Gruppierung dieser Funktionen, z. B. Namespaces in C ++.

— Gyan aka Gary Buyn

Es ist erwähnenswert, da man keine Sprache angegeben, dass in C ++ Sie können Klassen , um die nur statische Mitglieder und Zugang die Mitglieder über Vorlage passieren, und deshalb ist es möglich , dass eine Klasse mit nur statischen Elementen zu ersetzen, und wohl auch , die Methoden Form heißt es "Schnittstelle".

— DeadMG
quelle

vb.net / c # / java

— Pacerier