2010-06-24 16 views
5

devo strutturare nuovo modello per l'applicazione e non mi quello che è meglio:eredità o enum

utilizzando eredità o utilizzando enum come tipo di oggetto:

Ad esempio:

Libri

class Book 
{ 
public string Name {get;set;} 

public string Author {get;set;} 

public int NumberOfPages {get;set;} 

} 

public class Encyclopedie:Book 
{ 

} 

public class Novel:Book 
{ 

} 

o un uso migliore:

class Book 
{ 

public BookType Type {get;set;} 

public string Name {get;set;} 

public string Author {get;set;} 

public int NumberOfPages {get;set;} 

} 

public enum BookType 
{ 
Encyclopedie = 0, 
Novel = 1, 
... 
} 

risposta

21

Utilizzare l'ereditarietà se i diversi tipi presentano differenze significative (come elaborarli e trattarli). Cioè, se hai intenzione di usare il polimorfismo, dovresti usare l'ereditarietà.

Se hai solo bisogno di un modo per distinguere diversi tipi di libri, vai con l'Enum.

+0

Assolutamente d'accordo. Stavo pensando a come esprimere "differenze significative" solo ora. Povero inglese :( –

+1

D'accordo Sembra che voglia solo vederlo come tipi diversi L'ereditarietà fa un forte accoppiamento e cosa succede quando si ha un libro che attraversa i generi? Passare a C++ per consentire l'ereditarietà multipla? A [Flag] 'ed enum potrebbe essere una buona scelta qui – simendsjo

+0

+1 per una risposta molto chiara L'unica risposta giusta IMHO – pyrocumulus

0

Dipende davvero. La prima soluzione è meglio se hai bisogno di usare il polimorfismo. Dalla mia opinione personale, preferisco usare l'ereditarietà.

2

Direi che il secondo sarebbe meglio in quanto non si sta davvero estendendo la classe di libri nella propria Enciclopedia, non ci sono ulteriori proprietà o funzionalità necessarie per assegnare un tipo di libro a un altro.

2

"migliore" è soggettivo e fortemente dipendente dallo scopo della classe/modello. Qual è il tuo obiettivo? Cosa vuoi ottenere?-Al massimo a questo punto posso dire, l'ereditarietà è utile quando la classe derivata ha alcune proprietà abbastanza uniche - come l'Enciclopedie ha proprietà che spiegano quale tipo di Enciclopedie è in realtà e quelle proprietà non appartengono in alcun modo a un romanzo.

0

Se i diversi tipi di libri avranno attributi diversi, è necessario utilizzare un modello di ereditarietà. Ciò consente anche il polimorfismo, che di solito è migliore

Se tutti avranno gli stessi attributi, si potrebbe anche andare con l'enum. Ma tutto dipende dall'applicazione.

-1

utilizzando un enum per "digitare" l'oggetto suona un po 'di programmazione "vecchio stile C".

Voglio dire, è ok, ma quando l'ereditarietà è disponibile (stai usando C#) è generalmente una scelta migliore. Un enum generalmente introduce alcuni "problemi" ad esempio durante la serializzazione/deserializzazione dei dati: cosa succede se una vecchia versione della tua applicazione utilizza uno scenario "più recente" in cui un BookType ha un oggetto sconosciuto? (compatibilità backward/forward potrebbe essere un requisito per la tua app)

Ovviamente, puoi gestirlo con un bounch di "if-then-else" ma l'ereditarietà sembra una scelta più pulita dal mio punto di vista.

Ciao!

+0

Come distinguere tra classi ereditate quando deserializzare i dati? L'unico modo che vedo è quello di includere il nome della classe con ogni istanza di oggetto serializzato (che puoi fare anche chiamando tosting() su un enum) – apoorv020

+0

Un XmlSerializer restituisce dati digitati - certo che puoi usare un enum e accenderlo, ma perché farlo quando il "tipo" offre già la stessa cosa? Inoltre: se si utilizza solo una singola classe e un "enum" per digitarlo, sarà necessario inserire * tutte * le proprietà necessarie per i vari tipi in quel clas S. Probabilmente avrai una proprietà "XYZ" necessaria per tipo "BookAAA" ma non per tipo "NovelBBB" - e questo non è così buono, IMHO, quando puoi evitarlo per ereditarietà. –

0

Penso che dovresti fare questa scelta in base a ciò che il libro è "scopo". Se i libri non hanno bisogno di cose aggiuntive (metodi e proprietà ...), enum dovrebbe essere sufficiente. Se devi creare un comportamento comune per ogni libro e qualcos'altro più specifico per ogni tipo di libro hai ovviamente bisogno di ereditarietà (classe astratta "libro" e classi concrete).

3

Nei sistemi object oriented, il tipo di oggetto è trasparente per il client.Quindi il codice che gestisce i libri non dovrebbe sapere quale sia il tipo di libro, ma solo invocare metodi sui libri.

Quindi, se è necessario implementare un comportamento diverso all'interno del libro in risposta all'invocazione del metodo, estendere Libro e sovrascrivere alcuni dei suoi metodi. Se non lo fai, allora non farlo.

Appare, dati i corpi vuoti delle sottoclassi, che si comportano in tutto e per tutto come i libri. Quindi stai semplicemente taggando il libro con alcuni dati aggiuntivi - la differenza tra Encyclopaedia e Novel non è più essenziale per il libro di un libro con copertina rigida o softback o stampa di grandi dimensioni o stampa standard - un client può usarli in modo diverso, e ogni libro è un grande libro di stampa o è un libro di stampa standard, ma questi sono tutti attributi del libro piuttosto che differenze essenziali.

Non avrei bisogno di usare un enum per il tipo di libro, dato che potresti voler aggiungere più dati - o usare un sistema di codifica libero, quindi puoi taggare un libro con una serie di tipi - quindi tu avrebbe un libro etichettato come "bambini", "ornitologico", "enciclopedico", o consentire la struttura nei ruoli - quindi c'è un ruolo per "l'enciclopedia ornitologica dei bambini" creata quando è richiesta, ma non un'enumerazione fissa.