Progettazione di proprietà
Nota
Questo contenuto viene ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms and Patterns for Reusable .NET Libraries, 2nd Edition. Tale edizione è stata pubblicata nel 2008 e il libro è stato completamente rivisto nella terza edizione. Alcune informazioni in questa pagina potrebbero non essere aggiornate.
Anche se le proprietà sono tecnicamente molto simili ai metodi, sono piuttosto diverse in termini di scenari di utilizzo. Dovrebbero essere visti come campi intelligenti. Hanno la sintassi chiamante dei campi e la flessibilità dei metodi.
✔️ CREARE proprietà get-only se il chiamante non deve essere in grado di modificare il valore della proprietà.
Tenere presente che se il tipo della proprietà è un tipo riferimento modificabile, il valore della proprietà può essere modificato anche se la proprietà è solo get.
❌ NON fornire proprietà solo set o proprietà con il setter con accessibilità più ampia rispetto al getter.
Ad esempio, non usare proprietà con un setter pubblico e un getter protetto.
Se non è possibile specificare il getter della proprietà, implementare invece la funzionalità come metodo. Prendere in considerazione l'avvio del nome del metodo con Set e seguire il nome della proprietà. Ad esempio, AppDomain ha un metodo denominato SetCachePath invece di avere una proprietà solo set denominata CachePath.
✔️ FORNIRE valori predefiniti sensibili per tutte le proprietà, assicurandosi che le impostazioni predefinite non comportino una falla nella sicurezza o un codice terribilmente inefficiente.
✔️ CONSENTIRE di impostare le proprietà in qualsiasi ordine, anche se questo comporta uno stato temporaneo non valido dell'oggetto.
È comune che due o più proprietà siano correlate a un punto in cui alcuni valori di una proprietà potrebbero non essere validi in base ai valori di altre proprietà sullo stesso oggetto. In questi casi, le eccezioni risultanti dallo stato non valido devono essere posticipate fino a quando le proprietà correlate non vengono effettivamente usate insieme dall'oggetto.
✔️ MANTENERE il valore precedente se un setter di proprietà genera un'eccezione.
❌ EVITARE di generare eccezioni dai getter delle proprietà.
I getter delle proprietà devono essere operazioni semplici e non devono avere precondizioni. Se un getter può generare un'eccezione, è probabilmente necessario riprogettare in modo che sia un metodo. Si noti che questa regola non si applica agli indicizzatori, in cui si prevedono eccezioni in seguito alla convalida degli argomenti.
Struttura delle proprietà indicizzate
Una proprietà indicizzata è una proprietà speciale che può avere parametri e può essere chiamata con una sintassi speciale simile all'indicizzazione di matrici.
Le proprietà indicizzate sono comunemente denominate indicizzatori. Gli indicizzatori devono essere usati solo nelle API che forniscono l'accesso agli elementi in una raccolta logica. Ad esempio, una stringa è una raccolta di caratteri e l'indicizzatore su System.String è stato aggiunto per accedere ai relativi caratteri.
✔️ È CONSIGLIABILE usare gli indicizzatori per fornire l'accesso ai dati archiviati in una matrice interna.
✔️ VALUTARE la possibilità di fornire indicizzatori sui tipi che rappresentano raccolte di elementi.
❌ EVITARE di usare proprietà indicizzate con più di un parametro.
Se la progettazione richiede più parametri, riconsiderare se la proprietà rappresenta effettivamente una funzione di accesso a una raccolta logica. In caso contrario, utilizzare i metodi. Prendere in considerazione l'avvio del nome del metodo con Get o Set.
❌ EVITARE indicizzatori con tipi di parametro diversi da System.Int32, System.Int64, System.String, System.Object o un'enumerazione.
Se la progettazione richiede altri tipi di parametri, rivalutare fortemente se l'API rappresenta effettivamente una funzione di accesso a una raccolta logica. In caso contrario, usare un metodo. Prendere in considerazione l'avvio del nome del metodo con Get o Set.
✔️ Usare il nome Item per le proprietà indicizzate, a meno che non esista un nome ovviamente migliore (ad esempio, vedere la proprietà Chars[] in System.String).
In C#, gli indicizzatori sono denominati Item per impostazione predefinita. L’oggetto IndexerNameAttribute può essere usato per personalizzare questo nome.
❌ NON fornire sia un indicizzatore che dei metodi che sono semanticamente equivalenti.
❌ NON fornire più di una famiglia di indicizzatori di overload in un solo tipo.
Questa operazione viene applicata dal compilatore C#.
❌ NON utilizzare proprietà indicizzate non predefinite.
Questa operazione viene applicata dal compilatore C#.
Eventi di notifica delle modifiche delle proprietà
A volte è utile fornire un evento che informa l'utente delle modifiche apportate a un valore della proprietà. Ad esempio, System.Windows.Forms.Control genera un evento TextChanged dopo la modifica del valore della relativa proprietà Text.
✔️ PRENDERE IN CONSIDERAZIONE la generazione di eventi di notifica delle modifiche quando i valori delle proprietà nelle API di alto livello (in genere i componenti della finestra di progettazione) vengono modificati.
Se esiste uno scenario valido per un utente che deve sapere quando una proprietà di un oggetto viene modificata, l'oggetto deve generare un evento di notifica delle modifiche per la proprietà.
Tuttavia, è improbabile che valga la pena generare eventi di questo tipo per API di basso livello, ad esempio tipi di base o raccolte. Ad esempio, List<T> non genera tali eventi quando un nuovo elemento viene aggiunto all'elenco e la proprietà Count cambia.
✔️ PRENDERE IN CONSIDERAZIONE la generazione di eventi di notifica delle modifiche quando il valore di una proprietà cambia tramite forze esterne.
Se un valore della proprietà cambia tramite una forza esterna (in modo diverso dalla chiamata di metodi sull'oggetto), generare eventi indica allo sviluppatore che il valore sta cambiando e che è stato modificato. Un buon esempio è la proprietà Text di un controllo casella di testo. Quando l'utente digita testo in un oggetto TextBox, il valore della proprietà viene modificato automaticamente.
Parti protette da copyright © 2005, 2009 Microsoft Corporation. Tutti i diritti sono riservati.
Ristampato con l'autorizzazione di Pearson Education, Inc. da Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2a edizione di Krzysztof Cwalina and Brad Abrams, pubblicato il 22 ottobre 2008 da Addison-Wesley Professional nella collana Microsoft Windows Development Series.