Devrais-je utiliser moi-même mot-clé (Propriétés) dans la mise en œuvre?

Question

Je crois comprendre les propriétés pour la plupart. Ma question est la suivante: si je possède une propriété pour une variable d'instance et que je la configure ou la récupère depuis une méthode dans mon fichier d'implémentation, dois-je utiliser self.myProperty ou seulement myProperty? Je sais que l’une ou l’autre des solutions fonctionne, mais j’ai vu des conventions mixtes. Parfois, le code accède à la variable directement et d’autres fois via la propriété.

Y a-t-il une raison technique à cela? Est-ce juste une convention / préférence personnelle? Et je ne fais pas référence aux instances où le nom de paramètre d'une méthode entre en conflit avec le nom de variable d'instance, ce qui peut être une des raisons d'utiliser la propriété ( Du moins, dans d'autres langues, je ne le connais pas. un ). Je suppose que lorsque l'on utilise la propriété dans l'implémentation, ils veulent tirer parti de la façon dont ils ont déclaré la propriété ( c'est-à-dire nonatomic, Retenir ), afin de pouvoir, par exemple, utiliser une méthode. :

self.myProperty = [someObject someAutoReleasedObject];

au lieu de:

myProperty = [[someObject someAutoReleasedObject] retain];

Est-ce la raison? Alors, n’existe-t-il que certaines situations dans lesquelles il serait bon d’utiliser la propriété?

Je suis nouveau dans Objective-C et c’est l’une des rares choses qui m’a dérouté. Jusqu'à présent, je viens d'accéder directement à la variable d'instance, en supposant vraisemblablement que le fait de passer par la propriété appelle ou envoie une méthode / un message et ajoute une surcharge inutile. Je suis sûr que je me trompe, mais même si la différence de frais généraux est négligeable (le cas échéant), pourquoi choisirait-on de l’ajouter quand on peut simplement accéder directement à la variable?

Je suis sûr que je me trompe dans mon raisonnement, c'est pourquoi je pose la question ici.

Answer 1

Tout d’abord, vous ne devez pas utiliser de setters ni de getters dans init ou dealloc conformément à la documentation Apple (et pour de bonnes raisons).

En dehors de cela, vous devez généralement utiliser le paramètre de configuration pour définir la variable s'il en existe une.

Habituellement, je ne me soucie pas d'utiliser l'outil de lecture pour accéder à ivar depuis la mise en œuvre, mais il y a des moments où cela est nécessaire. En particulier, si vous vous attendez à ce que le getter effectue une vérification ou un calcul, ou si vous souhaitez autoriser des sous-classes à remplacer le comportement.

Certes, l’utilisation du getter dans la mise en œuvre est plus générale et plus sûre, mais elle est aussi généralement inutile et inutile. Faites votre choix.

Il est important d’utiliser le setter, car il permet aux autres codes d’observer les modifications (Key Value Observer), ainsi qu’aux sous-classes de remplacer le setter et d’effectuer les autres ajustements nécessaires.

Cependant, une chose que je recommande fortement est d'utiliser un nom différent pour votre ivar et votre propriété. La convention normale est un préfixe de soulignement (_), bien que j'utilise personnellement i_ comme préfixe pour éviter toute confusion avec l'utilisation privée d'Apple. De cette façon, vous ne pouvez pas utiliser accidentellement le mauvais:

self.name // use property
i_name // use ivar
self.i_name // syntax error
name // syntax error

Answer 2

Si vous exposez la propriété au monde extérieur et que vous l'utilisez en interne, utilisez-la dans votre code. La raison est l'encapsulation. Disons que vous avez un & Quot; Id & Quot; propriété pour SomeObj. Supposons qu'à un moment donné, vous décidiez de remplacer le comportement d'Id (peut-être avez-vous commencé avec Id en tant que membre de la classe et, au fil de l'évolution, deviendrait une donnée extraite de la base de données). Vous devez maintenant passer en revue votre implémentation de classe et remplacer toutes les références au membre var par des appels de base de données. Si vous aviez self.Id, il vous suffirait de remplacer le getter.