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.
fonte
2010-06-24 08:34:02
Assolutamente d'accordo. Stavo pensando a come esprimere "differenze significative" solo ora. Povero inglese :( –
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
+1 per una risposta molto chiara L'unica risposta giusta IMHO – pyrocumulus