ultimamente ho la sensazione che le variabili di istanza abbiano gli stessi problemi delle variabili globali, ho cercato su Google e ho trovato this old article che descrive più o meno il potenziale problema che sto vedendo.Le variabili di istanza sono le nuove variabili globali?
Quali buone pratiche si utilizzano per evitare che gli stessi problemi delle variabili globali influenzino variabili di istanza o variabili di classe?
Le classi sono molto più piccole della struttura globale, pertanto l'impatto di una variabile di istanza è molto minore. Mantenendo piccole classi e aderendo strettamente al singolo principio di responsabilità, si evita gran parte del rovescio della medaglia di una variabile globale. Se la variabile di istanza viene creata da un parametro passato in, allora spesso faccio quel parametro richiesto nel costruttore rendendo esplicita la dipendenza. Anche la variabile di istanza è incapsulata bene, non essendo mai modificata direttamente al di fuori dei metodi dell'istanza, rendendo molto facile determinare dove viene modificata la variabile di istanza. Infine, la variabile di istanza deve avere senso per la classe nel suo complesso o deve essere privata.
Le variabili di istanza sono accessibili solo all'interno di una classe specifica. Quindi, per evitare che le variabili di istanza vengano usate troppo spesso, mantieni le classi piccole. Se una classe diventa più grande, decidi se parti di essa possono essere refactored in un'altra classe più piccola, che la classe originale utilizza.
Né le variabili di istanza né le variabili globali né alcun tipo di variabile hanno "problemi" ... Sono tutti strumenti. Il problema è che a volte molti programmatori scelgono di utilizzare lo "strumento sbagliato". Devi pensare attentamente a cosa significano le tue scelte, in modo da poter fare la scelta giusta.
Utilizzo di una variabile globale per qualcosa, come CurrentUserName ... Significa che si sta dicendo che CurrentUserName è qualcosa di universalmente noto. E che "ci può essere solo un" CurrentUserName ogni volta. E probabilmente sarà falso se vuoi consentire agli utenti di essere loggati contemporaneamente (a meno che tu non sia davvero fortunato, e entrambi gli utenti abbiano lo stesso nome) ...
Un uso errato eseguito con variabili di istanza è se si inserisce l'indirizzo e-mail di un utente come variabile di istanza e quindi ci si rende conto che ciascun utente può disporre di più indirizzi e-mail.
Vorrei anche dare un esempio di ereditarietà, perché penso che renderà più chiaro: Un problema correlato con l'ereditarietà è ad esempio se si sta modellando il tipico Studente, problema Insegnante e si prova a fare Studente una sottoclasse di Persona e Insegnante una sottoclasse di Persona. E poi ti rendi conto che alcune persone potrebbero essere entrambe ...
Lo studente che eredita da Persona è una relazione statica che non può essere modificata in fase di runtime. E gli studenti e gli insegnanti non sono relazioni statiche ... Una persona non può essere né l'una né l'altra, quindi iniziare a essere uno studente, e quindi iniziare a essere un'insegnante, e quindi smettere di essere entrambe, e tuttavia sarà sempre la stessa persona, e quel modello non può gestire quello ....
Tornando all'utente, l'utente è "associato" con più account di posta elettronica ... Se si inserisce una variabile di istanza si sta affermando che è solo " associato "con un singolo account di posta elettronica, e tu stai contraddicendo il tuo dominio problema, ed è per questo che avrai problemi ...
Lo stesso vale se si dice che esiste solo un nome utente corrente globalmente conosciuto .. ..
Il problema in tutti i casi è t hai un dominio problematico e lo stai modellando in modo sbagliato ... Devi fare in modo che il tuo programma e il tuo modello si comportino in modo simile al dominio del problema ... Se non lo fai, avrai problemi , quale strumento scegli per risolvere il tuo problema.
BTW: Penso anche che l'utente abbia una lista di indirizzi e-mail sbagliata, ma è per una serie di motivi completamente diversa. Avevo in realtà uso un
class ContactInformation
{
User contact;
EMailAddress email;
}
e ricordo che gli oggetti non "possedere", né "avere" altri oggetti ... Questa è una decisione di implementazione ... Oggetti basta "sapere" altri oggetti ...