2009-08-05 21 views
5

Stavo osservando il modello di oggetto nullo e mi chiedo se valga la pena di implementarlo o utilizzare "se" per verificare i valori nulli nel mio codice intsead. Come ho osservato le implementazioni, sembra difficile mantenere gli oggetti ben sincronizzati con le loro implementazioni nulle. Apportando modifiche all'oggetto principale, dobbiamo verificare che l'oggetto nullo si comporti come previsto e sia facile fare errori di implementazione. Non è vero?Il modello di oggetto nullo vale la pena?

EDIT

Evitare il controllo di nulla: http://www.invisible-city.com/sharon/2009/03/null-object-pattern-when-slacker-is.html o http://journalofasoftwaredev.wordpress.com/2008/08/19/null-object-pattern-by-example/

+1

È possibile aggiungere una breve spiegazione o collegamento al "modello di oggetto nullo"? – thecoop

+0

http://jeremyjarrell.com/archive/2007/08/01/46.aspx –

risposta

2

Dalla mia esperienza non mi sembra difficile mantenere sincronizzato un oggetto Null. Se hai questo problema, il tuo oggetto potrebbe avere troppe responsabilità in quanto è soggetto a molti cambiamenti.

Tendo ad usare questo modello se posso effettivamente definire un tale oggetto in termini di lasciare un flusso di comportamento predefinito bene. Per esempio. Un oggetto Null per una manipolazione delle query è uno che lascia intatta la query originale. Un'estensione Null ad un altro oggetto è quella che non fa nulla.

Lo trovo a volte uno schema abbastanza pulito per evitare di verificare con ifs un comportamento facoltativo che può o non può esistere in un determinato stato della mia app.

4

Se l'oggetto essendo nulla sta per essere una norma in tutto il codice, ci si potrebbe anche utilizzare il modello. Controllo null quando un oggetto non è stato creato e deve essere istanziato. In realtà non uso null per qualcos'altro, e certamente non lo uso per non definire alcun comportamento.

Se, tuttavia, si utilizza nulla per indicare il comportamento non è stato ancora definito o il comportamento predefinito è niente, allora certamente utilizzare il modello.

0

Mi assicuro che i miei IEnumerable articoli sono vuote enumerazioni al posto di null, ma se qualcosa di veramente manca, cosa c'è di sbagliato con null? Occasionalmente devo distinguere tra inizializzato e manca in una situazione inizializzazione differita, ma poi Uso tipicamente una variabile booleana separato per indicare lo stato in modo qualsiasi valore (compreso null) è valida per l'oggetto di destinazione stessa.

2

Ho avuto un grande successo utilizzando oggetti nulli con le mie fabbriche e implementazioni IoC. Sono particolarmente utili per le funzioni verticali di un'applicazione. Non vorrei crearne uno per un'azione fondamentale per la tua applicazione.

Ad esempio, si dispone di un'interfaccia IPrinter e di un paio di oggetti che la implementano - PrinterX e NullPrinter. Nell'inizializzazione di IPrinter, è possibile provare ad avviare PrinterX, ma se non riesce, si restituisce invece un NullPrinter. In questo caso, la stampa è una funzionalità dell'app ma non è un requisito per il corretto funzionamento.

0

C'è molto malinteso sul modello di progettazione NULL che aiuta ad evitare i controlli NULL. In realtà, i vantaggi del sottoprodotto del modello di progettazione di oggetti NULL sono che non è necessario eseguire il controllo NULL. Ma i controlli NULL sono buoni e necessari. Il modello di progettazione NULL riempie l'assenza di oggetti e dovrebbe essere usato quando gli oggetti stanno collaborando con ciascuno di essi.

leggere questo articolo che parla di modello di progettazione oggetto NULL nel dettaglio

http://www.codeproject.com/Articles/1042674/NULL-Object-Design-Pattern

Alcune note su modello di progettazione NULL che eliminerebbe la confusione su questo modello.

  1. disegno NULL riempimenti un'assenza di un oggetto con un comportamento predefinito e deve essere utilizzato solo quando un oggetto collabora con altri.
  2. Il modello di progettazione NULL non è destinato a sostituire la gestione delle eccezioni NULL. È uno dei vantaggi collaterali del modello di progettazione NULL, ma l'intenzione è fornire un comportamento predefinito.
  3. I controlli NULL non devono essere sostituiti con oggetti modello di progettazione NULL in quanto possono portare a difetti muti dell'applicazione.
    1. Il modello di progettazione NULL è utile nel test delle unità Mock e nello sviluppo Agile.
    2. Le classi NULL sono classiche per l'applicazione del modello di progettazione Singleton e per rendere le classi immutabili.

Questo modello è visto soprattutto in combinazione con decoratore e fabbrica modello.