Paramètre par rapport à des variables membres

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

  •  22-08-2019
  •  | 
  •  

Question

J'ai récemment travaillé avec le code de quelqu'un d'autre et j'ai réalisé que cette personne a une philosophie très différente en ce qui concerne les variables privées et les paramètres de la méthode que je fais. Je me sens généralement que les variables privées ne devraient être utilisées dans le cas où:

  1. La variable doit être stocké pour un rappel ultérieur.
  2. Les données stockées dans la variable est utilisée globalement dans la classe.
  3. Lorsque la variable doit être manipulé à l'échelle mondiale (quelque chose de résolument différent de la nécessité de lire la variable par chaque méthode de classe).
  4. Quand il fera la programmation beaucoup plus facile. (Il est vrai que vague, mais on doit être dans de nombreuses circonstances pour éviter de se peindre dans un coin).

(je l'avoue, que beaucoup de ce qui précède sont un peu répétitive, mais chacun semble assez différent pour mériter un tel traitement ...)
Il semble juste que ce soit le moyen d'empêcher la modification d'une variable par accident le plus efficace. Il semble aussi que suivant ces normes permettra la manipulation éventuelle des références externes (si la classe est éventuellement modifiée), vous laissant ainsi avec des options supplémentaires à l'avenir. Est-ce simplement une question de style (comme un vrai support ou conventions de nommage hongrois), ou dois-je justifier dans cette croyance? Est-il vraiment une meilleure pratique dans ce cas?

modifier Je pense que cela doit être corrigé. Je « globalement » ci-dessus où je voulais dire, « globalement par les méthodes d'instance » et non « globalement accessible par tout, partout ».
Edit2 Un exemple a été demandé: 

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;
    }
}

Ceci est la façon dont je l'aurais fait: 

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;
    }
}
Était-ce utile?

La solution

En général, les membres de la classe devraient représenter État de l'objet de classe.

Ils ne sont pas des emplacements temporaires pour les paramètres de la méthode (qui est ce que les paramètres de la méthode sont pour).

Autres conseils

Je prétends que ce n'est pas une question de style, mais plutôt une question de lisibilité / maintenabilité. Une variable doit avoir une utilisation et une seule utilisation. variables « recyclage » à des fins différentes, simplement parce qu'ils arrivent à exiger le même type ne fait pas de sens.

D'après votre description, il semble que si le code d'une autre personne que vous avez travaillé fait exactement cela, puisque tous les autres usages sont essentiellement couverts par votre liste. Plus simplement, il utilise les variables membres privées à agir en tant que fonction de la situation temporaires. Ai-je raison de supposer cela? Dans ce cas, le code est horrible.

Plus le champ lexical et durée de vie d'une variable donnée, moins d'utilisation erronée possiblity et mieux pour l'élimination des ressources.

Avoir une variable membre implique qu'il tiendra l'état qui doit avoir lieu entre les appels de méthode. Si la valeur n'a pas besoin de vivre entre les appels, il n'a aucune raison d'exister en dehors du cadre d'un seul appel, et donc (si elle existe) devrait être une variable dans la méthode elle-même.

Le style est toujours une question difficile, une fois que vous développez un, vous pouvez vous retrouver dans un peu d'une ornière et il peut être difficile de voir pourquoi ce que vous faites peut-être pas la meilleure façon.

Vous ne devez créer des variables quand et où ils sont nécessaires, et en disposer lorsque vous avez terminé. Si la classe n'a pas besoin d'une variable de niveau de classe pour fonctionner, il n'a tout simplement pas besoin. Création de variables où vous n'avez pas besoin eux est très mauvaise pratique.

Les membres du groupe devraient être l'un des éléments suivants:

  • Une dépendance d'une classe
  • Une variable qui représente l'état de la classe
  • Procédé de la classe

Je ne suis pas sûr qu'il ya une meilleure pratique pour l'utilisation de variables indiqué globalement par rapport scope passant toujours en tant que paramètres de la méthode. (Par "variables privées", je suppose que vous voulez dire des variables globalement scope.)

En utilisant une échelle mondiale la variable scope est la seule façon d'implémenter des propriétés dans .NET (même des propriétés automatiques utiliser finalement une variable SCOPED globalement, mais pas celui que vous devez vous déclarer).

Il y a une ligne de arguement pour toujours utiliser des paramètres de méthode, car il rend tout à fait clair où la valeur vient. Je ne pense pas que cela aide vraiment empêcher la méthode d'apporter des modifications à la valeur sous-jacente et il peut, à mon avis, rendre les choses plus difficiles à lire parfois.

Je suis en désaccord avec la mise en œuvre pour un accès mondial ou pour faciliter la programmation. En exposant ces globalement sans filtrage d'aucune sorte de rendre plus difficile de déterminer l'accès à l'avenir.

Étant donné que les propriétés des objets sont destinés à maintenir l'état, comme indiqué par les autres, ma politique est d'avoir tous privés par défaut à moins d'avoir une bonne raison de les exposer.

Il est beaucoup plus facile de les rendre publics plus tard, si vous devez, en écrivant simplement une méthode de lecture par exemple (que je n'ai pas aussi de penser à droite au début de l'écriture d'une classe). Mais sous le choc dans une propriété publique plus tard peut nécessiter une énorme quantité de code à être réécrite.

Je tiens à le garder souple sans avoir à penser à ce plus que nécessaire.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top