Motivo di progettazione per le proprietà comuni: proprietà statiche o una classe di istanza singola separata?

1

Devo creare proprietà con valori comuni alle istanze di una classe. Non sono sicuro di come risolvere questo problema, quindi ho bisogno di aiuto. (Questo è in C #, ma non è una domanda specifica per la lingua.)

Ho letto le singole istanze (non un singleton), le proprietà statiche e altri pattern Questa domanda è vicina, ma l'unica risposta riguarda l'implementazione dei dati, non il codice. Dividere le definizioni degli oggetti (catalogo) dalle istanze (oggetti fisici)

Ho classi che vengono utilizzate come elenco di istanze, ad esempio catalogo di prodotti con caratteristiche diverse come un Baseball. Queste istanze contengono le proprietà che variano, ad esempio Colore, Logo.

public class Baseball
{
    public int ID { get; set; }

    public Color Color { get; set; }

    public string Logo { get; set; }
}

// Catalog code listing the baseballs
List<Baseball> Baseballs = ...

Devo creare proprietà con valori comuni a tutte le istanze. Questi non variano tra le istanze, ma saranno nel database, quindi non sono costanti. ad esempio, hanno tutti lo stesso prezzo e le stesse dimensioni.

public decimal Price { get; set; }

public int Size { get; set; }

Non so dove metterle. Non sono realmente descrittori di tipi nel codice, che descrivono la classe Baseball per i programmatori. I valori saranno nel database, quindi non sono costanti. I dati sono comuni a tutte le istanze di Baseball, ma non ad altre classi, quindi non si tratta di estendere una classe base da Ball.

EDIT con esempio migliore

Prezzo e dimensioni sono certamente proprietà che variano in genere con i prodotti, quindi non erano i migliori esempi. Il caso per questo è il contenuto dell'intestazione della sezione, che vedresti nella parte superiore della sezione del catalogo. ad esempio, Titolo ("Baseball") e una Descrizione ("Queste sono grandi palle da baseball").

Proprietà statiche

Ho visto alcuni esempi di proprietà statiche, ma sono principalmente utilizzati per dati di stato, non comuni. Inoltre tendono a essere scoraggiati come un tipo di variabile globale. La mia ipotesi è che sembrerebbe qualcosa di simile, ma questo non sembra giusto:

public class Baseball
{
    public int ID { get; set; }

    public Color Color { get; set; }

    public string Logo { get; set; }

    public static decimal Price { get; set; }

    public static int Size { get; set; }
}

Classe separata

Sono un grande fan di Active Record, ecco come vengono implementate queste classi di istanze. Tendo a propendere per la creazione di una nuova classe BaseballType o BaseballDefinition o BaseballCommon e la creazione di un'istanza. Ma questo non impone intrinsecamente un'istanza.

public class BaseballCommon
{
    public decimal Price { get; set; }

    public int Size { get; set; }
}

Dati

In relazione a questo, sto cercando di separare il pensiero sull'implementazione del database, quindi non guida la decisione della classe. Quindi, anche se sono separate le classi "comuni" separate, non è necessario creare un gruppo di tabelle di record attivo a un record. Forse una tabella di record nome / valore per ogni classe e proprietà. Sono anche curioso di sapere quale potrebbe essere quel modello? (o questa può essere una domanda separata dopo che questa è stata risposta).

    
posta goodeye 18.11.2018 - 04:25
fonte

1 risposta

2

La prima cosa che mi viene in mente è che le tue classi potrebbero essere troppo specializzate :

  • Considerare attentamente, se hai davvero bisogno di una classe Baseball , o se una classe Ball non estenderà l'utilizzo della tua classe (dopotutto un calcio potrebbe anche essere venduto con colori e loghi diversi, ma anche a un prezzo diverso). Forse la classe Item sarebbe ancora più generale.
  • Se sei in dubbio, usa la composizione piuttosto che statica. Statico richiederebbe sfere di prezzi diversi in classi diverse. Quindi se un giorno il proprietario del tuo negozio decidesse di avere articoli premium a prezzi più elevati, dovresti modificare il codice e creare una classe PremiumBaseball e StandardBaseball . Se usassi la composizione, potresti comunque condividere i prezzi per una famiglia di prodotti, ma non avresti bisogno di cambiare fondamentalmente il tuo codice.

Naturalmente, se tutto ciò fosse solo un ipotetico esempio di classe per un problema molto più semplice, e se la classe e la comunanza sono ben definite e sicuramente non si evolveranno, allora la statica potrebbe essere un'alternativa (inflessibile).

    
risposta data 18.11.2018 - 13:32
fonte

Leggi altre domande sui tag