Parametro vs.Variabili membro

Question

Recentemente ho lavorato con il codice di qualcun altro e mi sono reso conto che questa persona ha una filosofia molto diversa dalla mia riguardo alle variabili private e ai parametri del metodo.Generalmente ritengo che le variabili private dovrebbero essere utilizzate solo nel caso in cui:

1. La variabile deve essere memorizzata per essere richiamata in seguito.
2. I dati memorizzati nella variabile vengono utilizzati globalmente nella classe.
3. Quando la variabile necessita di essere manipolata globalmente (qualcosa di decisamente diverso dalla necessità di leggere la variabile con ogni metodo di classe).
4. Quando renderà la programmazione sostanzialmente più semplice.(Certamente vago, ma bisogna esserlo in molte circostanze per evitare di mettersi con l'angolo).

(Ammetto che molti dei precedenti sono leggermente ripetitivi, ma sembrano abbastanza diversi da meritare un simile trattamento...)

Sembra proprio che questo sia il mezzo più efficace per evitare di modificare accidentalmente una variabile.Sembra anche che seguire questi standard consentirà l'eventuale manipolazione di riferimenti esterni (se la classe viene eventualmente modificata), lasciandoti così con ulteriori opzioni in futuro.Si tratta semplicemente di una questione di stile (come una vera parentesi o le convenzioni di denominazione ungheresi), o ho una giustificazione in questa convinzione?Esiste davvero una best practice in questo caso?

modificare
Penso che questo debba essere corretto.Ho usato "globalmente" sopra dove in realtà intendevo "metodi globalmente per istanza" non "accessibili globalmente da qualsiasi cosa, ovunque".

modifica2
È stato chiesto un esempio:

class foo
{
    private $_my_private_variable;

    public function __constructor__()
    {
     }

    public function useFoo( $variable )
    {
        // This is the line I am wondering about,
        // there does not seem to be a need for storing it.
        $this->_my_private_variable = $variable; 
        $this->_doSometing();
    }

    private function _doSomething()
    {

        /*
          do something with $this->_my_private_variable.
        */
        // This is the only place _my_private_variable is used.
        echo $this->_my_private_variable;
    }
}

Questo è il modo in cui avrei fatto:

class foo
{

    public function __constructor__()
    {
     }

    public function useFoo( $variable )
    {
        $this->_doSometing( $variable );
    }

    private function _doSomething( $passed_variable )
    {
        /*
          do something with the parameter.
        */
        echo $passed_variable;
    }
}

Answer 1

In generale, i membri della classe dovrebbero rappresentare Stato dell'oggetto di classe.

Non sono luoghi temporanei per parametri di metodo (che è quello che i parametri del metodo sono per).

Answer 2

io sostengo che non è una questione di stile, ma piuttosto un problema di leggibilità / manutenibilità. Una variabile deve avere un solo impiego e un solo utilizzo. variabili “Riciclaggio” per scopi diversi solo perché capita di richiedere lo stesso tipo non ha alcun senso.

Dalla tua descrizione sembra come se il codice di un'altra persona che ha lavorato su fa esattamente questo, dal momento che tutti gli altri usi sono sostanzialmente coperti dalla vostra lista. In parole povere, si utilizza variabili membro private di agire come provvisori a seconda della situazione. Ho ragione di assumere questo? In tal caso, il codice è orribile.

Il più piccolo l'ambito lessicale e la durata di un dato variabile, il meno possiblity di utilizzo erroneo e meglio è per lo smaltimento delle risorse.

Answer 3

Avere una variabile membro implica che terrà stato che deve essere tenuto tra chiamate di metodo. Se il valore non ha bisogno di vivere tra chiamate non ha motivo di esistere fuori della portata di una singola chiamata, e quindi (se esiste affatto) dovrebbe essere una variabile all'interno del metodo stesso.

Lo stile è sempre un duro, una volta che si sviluppa quella che si può rimanere bloccati in un po 'di una carreggiata e può essere difficile capire perché quello che non può essere il modo migliore.

Answer 4

Si dovrebbe solo creare le variabili quando e dove sono necessari, e disporne quando si è fatto. Se la classe non ha bisogno di una variabile di livello di classe a funzionare, allora semplicemente non ne ha bisogno. Creazione di variabili in cui non hai bisogno di loro è molto cattiva pratica.

Answer 5

I membri della classe dovrebbe essere uno dei seguenti:

• Una dipendenza di una classe
• Una variabile che rappresenta lo stato della classe
• Un metodo della classe

Answer 6

Non sono sicuro che ci sia un dichiarato best-practice per l'utilizzo di variabili ambito globale contro passando sempre come parametri di metodo. (Con "variabili private", Sto assumendo vuoi dire variabili con ambito a livello globale.)

Utilizzo di una variabile di un ambito globale è l'unico modo per realizzare immobili a .NET (anche proprietà automatiche in ultima analisi, utilizzare un ambito globale variabile, non solo quello che si deve dichiarare se stessi).

C'è una linea di arguement per sempre utilizzando parametri di metodo perché rende tutto chiaro dove il valore proviene. Io non credo che davvero aiuta a prevenire il metodo di apportare modifiche al valore di fondo e può, a mio parere, rendere le cose più difficili da leggere, a volte.

Answer 7

Io sarei d'accordo con la sua attuazione per l'accesso globale o per rendere la programmazione più facile. Esponendo questi globalmente senza filtraggio di alcun tipo rendono più difficile determinare l'accesso in futuro.

Answer 8

Poiché le proprietà dell'oggetto hanno lo scopo di mantenere lo stato, come affermato dagli altri, la mia politica è di mantenerle tutte private per impostazione predefinita, a meno che non abbia una buona ragione per esporle.

È molto più semplice renderli pubblici in seguito, se necessario, semplicemente scrivendo un metodo getter, ad esempio (a cui non devo pensare nemmeno all'inizio della scrittura di una classe).Ma ritrovarsi in una proprietà pubblica in un secondo momento potrebbe richiedere la riscrittura di un'enorme quantità di codice.

Mi piace mantenerlo flessibile senza doverci pensare più del necessario.