3 Stimmen

Verstößt dies gegen die SOLID-Grundsätze?

Ich habe so etwas in meinem Projekt, das Projekt ist irgendwie schon fertig (es funktioniert) Ich möchte nur wissen, ob es mit den SOLID-Grundsätzen vereinbar ist.

static public class Tools
{
    static public GetProduct(this id){...}

    static public GetProductCategory(this id){...}

    static public GetUser(this id){...}

    // I also have here methods like IsStringNull ...
    // IsNull IsFalse, lots of stuff, everything static
}

und die Verwendung ist wie folgt

var UserThatCreatedCategoryForThisProduct = 
      prodId.GetProduct().CategoryId.GetProductCategory().Creator.GetUser();

Ich weiß, dass es offensichtlich ist, dass es die SRP verletzt, aber diese Klasse ist statisch und es enthält statische Methoden, die unabhängig voneinander sind, und es ist Art aus das gleiche, wenn ich eine statische Klasse für jede Methode erstellen würde

2 Stimmen

Das sind Erweiterungsmethoden? Die Syntax sieht ein wenig seltsam aus.

0 Stimmen

@peterchen: Das Anwendungsbeispiel zeigt, dass das definitiv der Plan ist, gut erkannt (ich habe es gelesen und nicht einmal bemerkt - das ist eine wirklich schlechte Idee!)

1 Stimmen

+1 Für eine gute Frage: Und ja... das verstößt gegen die SVB.

8voto

Jon Limjap Punkte 92084

Soweit ich sehen kann, gibt es hier eine Menge SOLID Verstöße!

  • Verstöße gegen das Prinzip der einzigen Verantwortung - Erstens haben Sie Datenzugriffsmethoden für mehrere Klassen, zweitens haben Sie Hilfsmethoden (IsStringNull, IsNull usw.), die mit diesen verflochten sind.
  • Verstöße gegen das Prinzip der Schnittstellensegragierung (wie von Ruben erwähnt) - Wenn ich mich nur um Produkte kümmern würde, warum brauche ich dann Methoden, die Benutzer erhalten?

Ich bin mir sicher, dass es noch einige andere gibt, aber das sind die wichtigsten.

UPDATE Jetzt, wo es jemand kommentiert hat, denke ich, dass er Recht hat; der obige Code sieht so aus, als wäre er eine Form von Missbrauch der Erweiterungsmethode .

Ich glaube zum Beispiel nicht, dass der Datenzugriff auf Erweiterungsmethoden oder, noch schlimmer, auf eine Klasse namens "Tools" reduziert werden sollte.

Es wäre wahrscheinlich sinnvoller, eine Basisklasse (auf einem völlig anderen Namespace und / oder Assembly) zu haben, die Ihre Datenzugriff Allgemeinheiten abstrahiert, dann erben eine Datenzugriffsklasse für jede eindeutige Domäne Objekt (z. B. UserDAO, ProductDAO, etc.). Verstehen Sie, dass ich hier davon ausgehe, dass Sie mit GetProduct oder GetUser eigentlich GetFromDatabase meinen.

Die übrigen Hilfsmethoden gehören zu den Erweiterungen, sind also in Ordnung.

2voto

Ruben Bartelink Punkte 57310

Ausgehend von Ihren Beispielen gibt es definitiv eine ISP und eine SRP und wahrscheinlich einen Verstoß gegen das Gesetz von Demeter (nicht SOLID, aber...).

IMNSHO sind Sie besser dran, wenn Sie die Artikel auf SOLID lesen (oder kaufen Agile Prinzipien, Muster und Praktiken in C# von Robert C. Martin und Micah Martin das durchweg hervorragend ist und zu den nützlichsten Büchern gehört, die ich in den letzten Jahren gelesen habe), als im Internet nach vereinzelten Ratschlägen für diese Art von Dingen zu fragen.

Wenn Sie eine Abkürzung suchen (müssen Sie aber nicht - die Bücher und PDFs haben Beispiele, die die Dinge sehr gut erklären!), sind diese Hanselminutes-Podcasts mit Onkel Bob sehr gut:

edit: Habe die SRP von Jon Limjap et ppiotrowicz

0voto

ppiotrowicz Punkte 4194

Es verstößt in vielerlei Hinsicht gegen die SOLID-Grundsätze.

  • Das Prinzip der einzigen Verantwortung wird nicht befolgt, da ich mindestens 3 verschiedene Dinge tue (Rücksendung von Produkten, Rücksendung von Kunden, String-Operationen).
  • es verstößt gegen den Grundsatz des offenen und geschlossenen Systems, da es nicht erweitert werden kann

CodeJaeger.com

CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.

Powered by:

X