2010-11-13 15 views
7

Sto provando a migliorare il mio stile di codifica. Si consideri il seguente scenario:
Supponiamo di voler definire un controllo server ASP.Net personalizzato. Lo scopo è di consentire all'utente di scegliere il tipo di album e tutte le altre cose verranno eseguite dal controllo.
Ho pensato a 2 approcci:Miglior modello di progettazione per lo scenario seguente

1- Definire un'interfaccia IAlbum e definire una classe (che implementa IAlbum) per ogni tipo di album. Ad esempio:

Quindi, se l'utente desidera un album flash, deve creare esplicitamente un oggetto FlashAlbum. qualcosa come:

var myFlashAlbum = new FlashAlbum(/*FlashAlbumParameters*/); 
var myJSAlbum = new JSAlbum(/*JSAlbumParameters*/); 

Il problema è che non voglio che l'utente abbia a che fare con più tipi di album. Leggi qui sotto per capire cosa intendo.

2- Definire iAlbum, definire una classe (che implementa iAlbum) per ogni tipo di album (come sopra) e definiscono Album classe che non implementare iAlbum. È usato per creare istanze di album nel suo contructor (modello factory). Definire EnumAlbumTypes:

Public Enum AlbumTypes 
{ 
    FlashAlbum, 
    JSAlbum 
} 

Ora definire un costruttore per la classe Parent album che prende il un parametro di tipo EnumAlbumTypes e crea l'album appropriata in base al parametro. Preferisco questo metodo. Ma non ho molta familiarità con il modello di fabbrica. Voglio che l'utente crei album come:

var myFlashAlbum = new Album(AlbumTypes.FlashAlbum); 
// Now set FlashAlbum custom properties. 
var myJSAlbum = new Album(AlbumTypes.JSAlbum); 
// Now set JSAlbum custom properties. 

Qual è l'approccio migliore per raggiungere questo obiettivo?
Grazie e scusa per il post lungo.

+0

Sembra che tu risponda alla tua stessa domanda. Il pattern factory sembra rispondere meglio alle tue aspettative che l'utente non debba gestire più tipi di album incapsulando la creazione di un tipo specifico. Quali preoccupazioni avete per l'implementazione di questo modello? –

+1

Come si può vedere nel mio codice, stavo chiamando la classe di fabbrica principale in modo errato. 'new Album (AlbumType.FlashAlbum)' è corretto. Dovrei chiamarlo come: 'AlbumFactory.Create (AlbumType.FlashAlbum)'. Post scriptum Dato che sono nuovo nell'usare modelli di design, volevo essere sicuro di essere sulla strada giusta. – Kamyar

risposta

4

Il modello di fabbrica è una buona opzione quando si desidera incapsulare la decisione sul tipo specifico di oggetto da creare. Il metodo dovrebbe restituire creare un tipo di album, quindi sarà:

var myFlashAlbum = Album.create(AlbumTypes.FlashAlbum); 
    var myJSAlbum = Album.create(AlbumTypes.JSALbum); 

Se il processo di costruzione degli album sono significativamente diversi si può prendere in considerazione il builder. Ti permette di incapsulare la complessa logica di creazione.

+0

Grazie! il modello del builder sembra interessante. – Kamyar

+1

anche le "var" possono essere sostituite da IAlbum. – Philipp

0

Se non vuoi che l'utente si preoccupi del tipo di album che hanno, allora perché stai dando loro la scelta?

L'ereditarietà sembra essere la scelta giusta qui. Non vedo alcuna prova o argomento a favore dell'altra opzione.

+0

Voglio che l'utente abbia un oggetto e sia in grado di cambiare lo stile di quell'album. non creare un oggetto di un altro tipo. – Kamyar

Problemi correlati