Tipps zu richtigen Klassen

Question

Ich benutze C#. Ich habe eine Produktklasse mit Feldern wie sku, name, description .... und Methoden wie setSku, setDescription, setImages (Produkte haben ein Bild angehängt). Ich habe diese Methoden in der Product-Klasse beibehalten, aber aufgrund der großen Menge von Einstellungen, die dem Client zur Verfügung standen, um die SKU und Beschreibungen und Bilder zu setzen, wurde die Klasse wirklich sehr groß. In der Klasse gab es viel Code. Also würde ich die große Produktklasse in Teile wie eine ProductSku-Klasse, ProductDescription-Klasse usw. aufteilen. Das Problem hierbei ist, dass einige der gleichen Felder auf alle Klassen zugreifen müssen. Ich begann, die Methoden für diese einzelnen Klassen aufzurufen und dieselben Objekte immer und immer wieder zu übergeben, aber das schien nicht richtig zu sein. So entschied ich mich jetzt, eine globale (mit Singleton-Muster) CurrentProduct-Klasse zu erstellen, die die Felder enthält, die ich für alle anderen Produktklassen benötige, die ich erstellt habe. Meine Fragen sind das klingt richtig und was würden Sie tun?

Das Programm, an dem ich gerade arbeite, nimmt auf einer einfachen Ebene Produkte aus einer Tabelle aus der Datenbank1 und speichert die Produkte in einer Tabelle auf der Datenbank2. Den Benutzern stehen jedoch viele Einstellungen zur Verfügung, wie sie die Felder, die von database1 kommen, aussehen sollen, wenn sie in die Datenbank2 eintreten.

Zur Klärung: Die oben genannten Methoden set und get sind keine Getter- und Setter-Methoden. Ich verwende Eigenschaften, aber ich nannte sie gesetzt, weil es viel Code gibt, der in die Formatierung einiger Felder vor der Aktualisierung geht. Ich verstehe die Verwirrung und entschuldige mich dafür, dass ich nicht geklärt habe.

Answer 1

Der Singleton für das aktuelle Produkt klingt schlecht. Sie rufen eine globale Variable nur unter einem anderen Namen auf.

Ich weiß nicht, was ein Sku ist, aber für den Rest (Beschreibung und Bilder), wenn sie Attribute eines Produkts sind (was ich denke, sie sind) gehören sie in die Produktklasse.

Wenn Sie Ihre "Klassenstücke" zusammen herumreichen, ist das ein starkes Zeichen, dass sie zusammengehören. Wenn Sie möchten, trennen Sie den Code (nicht die Klasse) in mehrere Dateien, indem Sie das Schlüsselwort partial verwenden. Wie folgt aus:

// This file is Product.CodeAboutThingA.cs 

public partial class Product 
{ 
    // Some stuff related to A here... 
} 

Und in einer anderen Datei:

// This file is Product.CodeAboutThingB.cs 

public partial class Product 
{ 
    // Some stuff related to B here... 
} 

Answer 2

Vielleicht sollten Sie darüber nachdenken, es zurück zu einer Klasse zu verschmelzen, aber um es lesbar zu machen verwenden teilweise Modifikator?

Eine andere Antwort wäre, abstrakte Klasse Product zu erstellen und spezialisierte Klassen daraus zu erben.

Answer 3

Um meine 0,5 Cent zu geben, eine Klasse, die nur durch die Spaltung es in partials hat durchaus einen Code Geruch verwaltet werden können. Das Ganze in mehrere Klassen zu trennen klingt gut, besonders wenn man Sachen wie SKU etc. bereits als eigene Klasse identifiziert hat.

Dinge, die Sie sich stellen sollten, sind ...

• Ist es in Ordnung, wenn ich nur eine SKU über eine gültige Instanz zugreifen können? Selbst wenn es nur ein Identifizierer ist, kann ein solcher Identifizierer in sich ziemlich komplex sein.
• In welcher Weise muss die SKU Zeug aus der Produktklasse verwenden?Wenn das Produkt die einzige ist, die eine SKU instanziiert, kann es in Ordnung sein, das Produkt in die SKU zu geben. Die beiden Klassen sind jetzt ziemlich eng gekoppelt, aber immer noch besser als ein einziges Produkt-Chaos ohne Semantik.
• Können Sie feststellen, welche Teile gemeinsam verwendet werden müssen? Vielleicht fehlt Ihnen eine Entität oder ein Wertobjekt, das das "gemeinsame Teil" ist?
• Vielleicht würden Sie mit einem Product Builder glücklicher sein, anstatt den Kunden die Innereien einer Produktinstanz durchwühlen zu lassen?

Aus meiner Sicht, wenn Sie eine Klasse mit 1k + Zeilen Code haben, gibt es noch eine Menge Verständnis fehlt, was Ihr „Produkt“ wirklich ist und wie es sich verhält im Rahmen Ihrer Bewerbung ...