variabili membro vs. stato Varaibels? Sono gli stessi? [chiuso]

È davvero difficile dare buoni consigli su un argomento così ampio. La risposta onesta è: dipende da cosa vuoi ottenere.

1) Le variabili membro potrebbero rappresentare lo stato di un oggetto. Questo potrebbe o potrebbe non essere, ciò che intendevi fare. Se il tuo oggetto vive in un contesto web / concorrente, allora questo è il più delle volte no, quello che vuoi. In questi contesti, la maggior parte delle volte si desidera apolidia / immutabilità . Se un oggetto è condiviso e le letture e le scritture sono consentite, ci sono problemi. Naturalmente ci sono modi per evitare tali problemi (ad es. Serrature ecc.) Ma non è una buona idea avere oggetti mutabili .

2) Un altro caso per le variabili membro è di mantenere le dipendenze per l'oggetto: ad es. dipendenze da repository, servizi, ecc. Queste sono la maggior parte delle volte iniettate una volta ; a volte tramite constructor-injection o tramite setter-injection . Non avrebbe senso evitare l'uso di membrane per queste dipendenze; d'altra parte dovresti iniettare le dipendenze necessarie con ogni chiamata di funzione. Questo inquina la firma del metodo non necessaria e rende complicato l'uso della tua API.

3) E c'è lo spazio in mezzo. Se un oggetto non è condiviso e la membra- nariabile non rappresenta una dipendenza che sei libero di fare, ciò che ti piace. È sbagliato considerarli come variabili globali poiché non sono globali: sono limitati all'oggetto. E un pilastro del design orientato agli oggetti è incapsulamento o nascondere le informazioni . È come ballare nudi nel tuo salotto: finché nessuno lo vede - a chi importa?

Una variabile membro è una variabile che è portata alla classe. Ciò significa che qualsiasi codice all'interno della classe può accedere alla variabile. Il modo in cui la variabile viene utilizzata o il modo in cui viene utilizzata non ha importanza, rispetto al suo stato membro . Le variabili membro e lo stato classe / oggetto sono la stessa cosa.

Esempio:

public class MyClass
{
   // Not a member variable; never changes.
   private const pi = 3.14159;

   // class state; member variable, but shared with all object instances. 
   private static object locker;

   // member variable.
   private List<double> list;

   // member variable.
   private int counter;

   // member variable, but properties are preferred.
   public bool IsSingleton; 

   // not a member variable; part of the class's external API.
   public int Counter
   {
       get { return counter; }
   }

   public double CalculateAverage
   {
       // not a member variable; scoped to method.
       double sum;

       for (int i=0; i< list.Length; i++)
       {
           sum += list[i];
       }
       return sum / list.Length;
   }   
}

Un uso di "dichiarare le variabili come membri" è per gli attributi . Essendo le cose che descrivono la cosa che stai modellando, forse, qualche consumatore esterno vorrebbe chiedere. Ad esempio il nome e l'età di una persona sono esempi di attributi. Questi attributi sono solitamente modificati usando un metodo setter e letti usando un metodo getter.

Gli attributi fanno parte dello "stato" di un oggetto. Ma anche altre variabili oltre agli attributi fanno parte dello stato.

Il secondo uso possibile è per quei tipi di variabili. Tali variabili contengono informazioni che di solito vengono lette e scritte da diversi metodi di classe.

Esempi:

• un contatore interno (non i contatori nei cicli for)
• una connessione al database aperta
• un elenco di articoli elaborati
• una bandiera che indica che l'oggetto si trova in un determinato stato (in attesa, chiuso, aperto, disponibile, ecc.)

Queste variabili sono candidate per essere variabili membro anche quando nessuno al di fuori della classe ha bisogno di conoscerle.

Ciò che dici del passaggio di tutto come parametri ai metodi indica che tali metodi non sono coerenti con la classe e che dovrebbero essere statici.

Forse non stai modellando i concetti del mondo reale in un modo OO e stai semplicemente usando le classi come applicazioni, cioè l'applicazione è la classe, ed è per questo che non trovi naturale dichiarare le variabili dei membri.

Un altro suggerimento è che se scopri di passare costantemente lo stesso parametro tra più metodi, è probabile che quel metodo debba essere un membro.

Recomendation:

Utilizza le classi per modellare entità reali, come BankAccount, Player, Chessman, ecc. Non creare classi giganti con un metodo principale gigante e molte funzioni di aiuto.