Best practice: proprietà accessore o metodi senza parametri?

StackOverflow https://stackoverflow.com/questions/1389355

Domanda

che è la pratica migliore e perché? 

bool IsTodayMonday { get { return DateTime.Now.DayOfWeek == DayOfWeek.Monday; } }

o 

bool IsTodayMonday()
{
    return DateTime.Now.DayOfWeek == DayOfWeek.Monday;
}
È stato utile?

Soluzione

Per me - in questo caso specifico -. Non importa a tutti

Se si dà un'occhiata alla IL-codice generato si noterà che è esattamente lo stesso. La proprietà causerà un metodo da creare, che produce lo stesso codice IL.

Per quanto riguarda le implementazioni .NET, probabilmente si dovrebbe utilizzare la proprietà. Il quadro Net utilizza immobili in IsXXX-Funzionalità quando nessun parametro è in uso, altrimenti esso utilizza metodi salvo alcune altre cose indicano l'uso di un metodo è più appropriato. (Vedi post sopra per gli esempi di questo)

Questa è la IL-codice prodotto da entrambe le versioni nel caso in cui si è interessati (io ho usato una semplice console app e metodi statici / proprietà) 

{
  // Code size       22 (0x16)
  .maxstack  2
  .locals init ([0] bool CS$1$0000,
           [1] valuetype [mscorlib]System.DateTime CS$0$0001)
  IL_0000:  nop
  IL_0001:  call       valuetype [mscorlib]System.DateTime [mscorlib]System.DateTime::get_Now()
  IL_0006:  stloc.1
  IL_0007:  ldloca.s   CS$0$0001
  IL_0009:  call       instance valuetype [mscorlib]System.DayOfWeek [mscorlib]System.DateTime::get_DayOfWeek()
  IL_000e:  ldc.i4.1
  IL_000f:  ceq
  IL_0011:  stloc.0
  IL_0012:  br.s       IL_0014
  IL_0014:  ldloc.0
  IL_0015:  ret
} // end of method Program::get_IsTodayProp

Cheers!

Altri suggerimenti

A mio avviso, utilizzare le proprietà in queste situazioni a meno che:

  • La chiamata è costoso, per esempio chiamate al database sono in corso
  • Non ci sono effetti collaterali quando si chiama la proprietà, per esempio altre variabili vengono impostate come pure
  • Chiamare i tempi di proprietà multipla produce risultati differenti
  • La tua struttura viene utilizzata solo per impostare i valori

Nel tuo esempio, vorrei andare con una proprietà.

Una proprietà dovrebbe essere un wrapper abbastanza banale per un valore. Per l'utente di una proprietà, dovrebbe agire come una variabile.

Se lo fa qualsiasi quantità di lavoro, ha effetti collaterali (ad esempio, la lettura / scrittura cambia qualche altro stato nella classe), o se potrebbe non riuscire (ad esempio generare eccezioni), allora è meglio scrivere come un metodo Get , in modo che il chiamante può vedere che non è solo un semplice valore.

Al di là di questo, è più di preferenze personali (se si sente Proprietà dovrebbero rappresentare solo variabili membro di cemento, o se possano essere utilizzate per leggere "valori calcolati" come quello nel tuo esempio).

In generale:

Se stai usando un linguaggio in cui l'opzione # 1 è legale, allora si dovrebbe usarlo. Aumenta la leggibilità ed ha fatto esattamente per questo tipo di lavoro.

Se non è possibile utilizzare l'opzione # 1, è necessario utilizzare metodi di ottenere / set; vale a dire:. 

bool getIsTodayMonday()
void setIsTodayMonday(bool timetravelingArgument)

Il tuo esempio specifico

Penso che si può trovare con argomenti per entrambe, anche se mi piacerebbe andare con l'opzione # 2 come campi (a mio avviso) non dovrebbe fare troppi calcoli (ad eccezione per la convalida e forse la trasformazione).

Per quanto mi riguarda, direi IsTodayMonday sembra più un metodo che una proprietà quindi vorrei andare con la seconda opzione Vedere Metodo vs proprietà in C # -. qual è la differenza per un buon esempio di quando utilizzare le proprietà rispetto ai metodi

Vorrei scegliere a seconda di ciò che si vuole comunicare con l'utente e quello che sta succedendo nel metodo. Nel tuo esempio mi sarebbe probabilmente andare per la prima versione. Se il calcolo è più complesso, vorrei andare per la seconda versione.

o da un punto di vista degli utenti: Non mi dispiacerebbe accesso obj.IsTodayMonday più volte, perché presumo che non ha bisogno di calcoli pesanti. In caso di obj.IsTodayMonday () che ci avrei pensato caching e riutilizzo del risultato.

Ma questo è, naturalmente, il mio modo di scrivere codice. Dipende dalle vostre politiche.

Clock.IsTodayMonday suggerisce a me che questo non ha effetti collaterali o calcoli.

Clock.IsTodayMonday() indica che ci possono effetti collaterali o calcoli.

Nel tuo caso, IsTodayMonday forse del caso, ma come va e interroga l'orologio di sistema, può essere più appropriato chiamarla IsTodayMonday().

Un esempio più complesso forse PrimeFactors. Se tu avessi una proprietà di un intero chiamato PrimeFactors, indicherebbe a me che si potrebbe chiamare di volta in volta senza alcun calo di prestazioni. Tuttavia, se ci fosse un metodo chiamato PrimeFactors() allora probabilmente sarei usare una variabile temporanea per memorizzare nella cache il risultato se avevo bisogno di più di una volta, soprattutto in un loop stretto.

DataBinding non funziona su metodi, quindi se mai intenzione di vincolare il proprio oggetto per un certo controllo, tenere questo in mente. Personalmente preferisco le proprietà, per motivi di leggibilità.

Avete considerato 

public static bool IsMonday(DateTime date)
{
    return date.DayOfWeek == DayOfWeek.Monday;
}

, invece? Questo è significativamente più facile da test di unità rispetto al metodo originale.

Ho venti anni o giù di lì di esperienza nella progettazione di software come consulente per un certo numero di aziende diverse e hanno anche lavorato presso l'azienda OEM. Per me questa domanda è più simile a una politica aziendale (linee guida di codifica) domanda e se ogni azienda vuole scegliere i metodi che aiutano a produrre facile da capire e facile da eseguire il debug e leggere le pratiche, poi si dovrebbe scegliere utilizzando get / set sopra le proprietà. Questo perché, ad esempio, durante il debug di una classe chiamata che utilizza una proprietà da altra classe sembra che ci come un potenzialmente non ben gestito l'accesso variabile pubblica (BAD e sembra pericolosa). D'altra parte, se si vedrebbe una chiamata di metodo getter / setter lì, allora si dovrebbe sapere subito, che non si tratta di un accesso variabile pubblica e che ci sia una gestione della chiamata di funzione e può anche tornare il codice di errore o eccezione , se così scelto. Ogni linea guida di codifica o la selezione pratica dovrebbe essere basata sul fatto, che le guide che la selezione migliori programmatori di scrivere rapidamente comprensibile, affidabile (sicuro), codice portabile, semplice e simmetrica, che è il debug -friendly. E ci dovrebbe essere altri motivi?

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top