6
votes

Quels sont les avantages de l'utilisation de propriétés en interne?

L'encapsulation est évidemment utile et essentielle lorsque vous accédez aux membres de l'extérieur de la classe, mais lorsque vous faites référence à des variables de classe en interne, est-il préférable d'appeler leurs membres privés ou d'utiliser leurs getters? Si votre getter renvoie simplement la variable, existe une différence de performance ?


4 commentaires

Essayez de vous poser votre question: Si vous croyez que votre propre déclaration (que je ne vois aucune raison pour laquelle vous ne devriez pas) «L'encapsulation est évidemment utile et essentielle lorsque vous accédez à des membres de l'extérieur de la classe», essayez ensuite de trouver un argument solide pour Pourquoi les choses devraient être différentes si vous avez retiré les quatre derniers mots. Si vous ne pouvez pas savoir que vous pouvez utiliser les mêmes arguments :)


@CHRISF: Ce fil est à peu près indépendant à cette question


Lien vers ce qui s'est avéré être une question non pertinente supprimée.


duplicaté possible de . -A-variable-dans-le-le-de-lame-CLASS-A-PRO PERTY


5 Réponses :


9
votes

Il ne devrait pas y avoir une différence de performance significative et la raison pour laquelle vous vous tenez à l'aide des propriétés est parce que c'est tout le point d'encapsulation. Il conserve tous les accès de ces membres privés cohérents et contrôlés. Donc, si vous souhaitez modifier la propriété Getter / Setter, vous n'avez pas à penser "Dois-je dupliquer la même fonctionnalité ailleurs dans les endroits où j'ai décidé d'accéder directement au membre privé directement?"


0 commentaires

4
votes

La prestation serait dans les cas où il y avait une validation à effectuer sur le get ou l'ensemble. Ce serait au même endroit et toujours appelé.

Autant que je sache (à partir d'autres questions posées sur le débordement de la pile) Lorsque le getter renvoie simplement la valeur que générée est la même que pour accéder directement à la variable.


0 commentaires

7
votes

Accéder directement au terrain ou utiliser Getter ne fait généralement pas une grande différence, à moins que votre getter effectue une initialisation paresseuse ou une autre transformation. Cela dépend donc de ce que le getter fait, mais ma règle de base est de toujours utiliser le getter sauf dans des cas spécifiques.

Pour attribuer une valeur au champ, n'oubliez pas que les régleurs incluent souvent le code de validation ou soulever un événement. Dans ce cas, vous devez toujours utiliser le setter.


2 commentaires

+1: C'est une bonne règle de base. Il y a une tendance générale à utiliser le membre privé .. «Je ne fais rien dans le getter et / ou le setter. . " (coupable..je l'admettez-le) puis plus tard vous, pire quelqu'un d'autre, ajoute une certaine validation au setter et ... Bang ... votre cible à un qui a tiré sur la réunion de lapin. Comme Thomas a dit..Ille est toujours une pièce pour une exemption de cas spéciale ... par habitude utilisez le setter.


Quoi qu'il en soit, des getters simples ou des setters sont généralement inlinés par le compilateur JIT, ce n'est donc même pas une optimisation d'accéder directement au champ ...



2
votes

La différence de performance est négligeable, dans environ 98% du temps.

Vous devez toujours utiliser des propriétés même si votre getter ou votre setter obtenez ou définissez votre membre privé. Cela vous permettra d'apporter des modifications lorsque votre demande évolue. Ce faisant, vous pourrez apporter des restrictions ou une autre encapsulation dans vos propriétés sans casser votre code. Sinon, une fois que vous avez décidé d'écrire des propriétés en raison d'une raison X, vous vous trouverez obligé de refroidir tout votre code pour obtenir ou définir la propriété au lieu de votre membre privé.


0 commentaires

1
votes

J'aime utiliser des propriétés internes pour l'initialisation paresseuse, où dans la propriété, vous assurez que l'objet est initialisé. Cela garantit que je n'utilise pas de variables de niveau de classe qui n'ont pas encore été initialisées. xxx


0 commentaires