Dois-je consulter pour soi.propriété dans la méthode init avec l'ARC?

Une question rapide.

si j'ai une propriété et d'un ivar déclarée avec le même nom:

dans le .h fichier:

(Reminder*)reminder;
@property(nonatomic,strong)(Reminder*)reminder;

dans le .m fichier, dois-je utiliser le ivar ou à la propriété dans la méthode init si je suis en utilisant l'ARC?

- (id)initWithReminder:(Reminder*)reminder_ {
    self = [super init];
    if (self) {
        reminder = reminder_;
    }
    return self;
}

Ou dois-je utiliser la propriété pour obtenir le bénéfice de l'automatique de comptage de référence comme ceci:

- (id)initWithReminder:(Reminder*)reminder_ {
    self = [super init];
    if (self) {
        self.reminder = reminder_;
    }
    return self;
}

Je ne suis pas sûr à quel point dans l'objet de l'initialisation des propriétés deviennent accessibles avec la notation par points.

  • si vous utilisez synthétiser (je suppose que oui) et que vous utilisez un compilateur moderne (je suppose que vous faites en raison de ios5), vous n'avez pas besoin de déclarer le ivar, objective-c le fait automatiquement pour vous. (ce n'est pas la réponse à votre question, juste une note).
  • C'est une bonne chose à savoir, j'ai toujours déclaré ivars pour les propriétés jusqu'à maintenant. Et oui, je fais @synthétiser de la propriété avec le nom par défaut.
  • Était sur le point de vous dire la même chose que @choix. Et je crois que vous avez toujours obtenir le bénéfice de l'ARC, indépendamment de si oui ou non vous utilisez la propriété.
  • Vous n'avez même pas besoin @synthesize
InformationsquelleAutor Alex Stone | 2011-11-08
  1. 67

    Utiliser l'accès direct partiellement construit états membres, indépendamment de l'ARC:

    - (id)initWithReminder:(Reminder*)reminder_ {
    self = [super init];
    if (self) {
        reminder = reminder_;
        //OR
        reminder = [reminder_ retain];
    }
    return self;
}

    C'est parce que self.whatever va déclencher d'autres effets secondaires, tels que la Clé-Valeur d'Observation (KVO) les notifications, ou peut-être votre classe implémente (explicitement) ou une sous-classe remplace setWhatever: -- et qui pourrait exposer vos partiellement initialisé exemple à d'autres Api (y compris ses propres), qui, à juste titre supposer qu'ils ont affaire avec un objet construit.

    Vous pourrait vérifier manuellement qu'une classe est capable de fonctionner dans une partie initialisé à l'état, mais qui nécessite beaucoup d'entretien, et (franchement) difficile ou impossible, si d'autres personnes veulent votre sous-classe de la classe. Il exige beaucoup de temps et d'entretien, et il n'y a pas substantiative avantage de le faire, surtout si vous essayez d'utiliser l'approche de la convention.

    Donc l'uniforme qui garantit l'exactitude est d'utiliser l'accès direct partiellement construit unis, et éviter d'utiliser les accesseurs.

    Note: j'utilise "partiellement construit" parce que l'initialisation n'est que la moitié de l'image; -dealloc a les mêmes mises en garde.

    Un peu plus en détail pourquoi vous devriez utiliser l'accès direct partiellement construit unis (ARC || MRC) peut être trouvé ici: L'initialisation d'une propriété, la notation point

    • Je suis un peu confus par cela quand il s'agit de la sous-classe. Si nous ne devrions pas utiliser l'auto.propertyName dans l'init méthodes, comment voulez-vous accéder à un parent de la classe de la propriété à l'intérieur de la méthode d'initialisation d'une sous-classe ? à l'aide de _propertyName dans la sous-classe dit variable non déclarée, la seule solution est d'utiliser l'auto.propertyName. Exemple: stackoverflow.com/questions/16622776/...
    • en général, vous devriez éviter aux propriétés de la classe de base dans les initialiseurs. cette approche nécessite de votre classe dérivée de savoir à propos de sa super-classe de mise en œuvre, ainsi que toutes les classes dérivées qui pourrait remplacer l'accesseur implémentations. en objc, vous pouvez retrouvez l'appel (le non initialisée) dérivée de la classe de substituée aux méthodes d'accès. ainsi, vous pouvez éviter ce mal de tête/risques: en suivant les conseils ci-dessus, en fournissant plus approprié initialiseurs, en utilisant les accesseurs entièrement construite cas, en utilisant moins de types complexes (composition), de la commodité, constructeurs, etc.
    • Je pense qu'il est sûr de propriétés de l'appel de super-classe dans la sous-classe " init. Au moment où vous atteignez le "corps" de la sous-classe "init, qui est une superclasse" init doit l'avoir déjà fini. Cela signifie, d'une super-classe est lui-même (ou au moins devrait être, s'il est écrit correctement) déjà initialisé complètement. Ainsi, l'accès à son (= super-classe") propriétés doivent être en sécurité - même si vous remplacez la propriété dans la sous-classe. Le problème est lorsque vous accédez à la propriété dans l'init dans une superclasse. Dans de tels cas, si vous substituez setter dans la sous-classe, vous pouvez y arriver avec partiellement initialisé objet.
    • ce n'est pas très sûr, surtout que la complexité des hiérarchies de classes et les classes de l'augmentation: stackoverflow.com/questions/5932677/... -- vrai, on peut faire un prouvable de conception sûre mais qui veut vérifier que reste sûr, chaque fois que les implémentations sont-elles modifiées? c'est compliqué/fastidieux/enclins à faire des erreurs et ne pas acheter de vous.
    • ok, donc quand je sous-classe UITableViewCell et souhaitez ajouter pour ajouter un peu de custom UIView comme une sous-vue à son contentView lors de l'initialisation, ce qui devrait je faire à la place de: [self.contentView addSubview:someSubview]; ?
    • dans l'ensemble, vous, l'idéal serait d'effectuer une telle installation une fois tous les initialiseurs d'avoir exécuté et l'instance est complètement initialisé. peut-être que c'est dans un -awakeFromNib, l'initialisation différée, ou d'une autre phase de l'installation -- dépend de l'objet.
    • Si je construis mon UITableViewCell sous-classe dans le code (vous ne pouvez pas dire que c'est interdit), puis awakeFromNib n'est pas une option. À l'aide de l'initialisation tardive dans de tels cas est à mon avis simple solution de contournement du problème. J'utilise l'initialisation tardive, seulement quand il est logique (par exemple, lorsque la non-lazy init est le goulot d'étranglement qui est plutôt PAS le cas ici) - pas dans le but de s'en tenir à quelques autres (tout à fait non-liés) les règles... Mais ok, je pense que nous venons d'avoir deux approches différentes et des priorités que nous appliquons à notre code 🙂
    • J'ai prévu une troisième, très large, option: "une autre étape de la configuration dépend de l'objet". Peut-être que c'est le code dans le domaine client, un remplacement, une commodité constructeur, propriété implémentations, etc. - vous pouvez aborder les problèmes de beaucoup de manières dans le code. Il n'y a pas un seul qui convient à chaque application idéalement, et certainement trop grand nombre de variantes pour les champs de commentaire.

    InformationsquelleAutor justin
  2. 5

    Non, vous ne devriez pas!

    Vous pouvez trouver la description de la raison de ici

    Aussi apple recommande de ne pas le faire. Lire ici

    InformationsquelleAutor Kostiantyn Koval
  3. 0

    Je ne suis pas sûr à quel point dans l'objet de l'initialisation des propriétés deviennent accessibles avec la notation par points.

    Depuis le point est toujours un Objectif-C (et C méthode réellement en vertu de l'ObjC méthode) la notation par points, ou l'appel de la méthode, est parfaitement sûr, étant DONNÉ la méthode est prêt à traiter avec le type sous-jacent(s) en mémoire dans quel état ils se trouvent.
    La règle normale sur la façon d'éviter l'utilisation d'un uninitiatilized (peut-être) le garage d'un segment de mémoire encore s'appliquerait. Qui est la plus forte motivation pour l'utilisation de la ivar dans l'init.

    Mais si votre méthode (getter|setter) est capable d'utiliser correctement le segment de mémoire, que c'est d'abord écrit avant de le lire -, puis par tous les moyens à utiliser votre getter dans la méthode init.
    Un Paresseux getter tire parti de l'hypothèse qu'un pointeur, il va initialiser commence comme " nil " de décider sur l'exécution de l'initialisation. Si vous ne pouvez pas assumer le contenu initial de votre mémoire, puis l'initialisation de la ivar peut-être le plus sûr.

    Pourquoi la règle de ne jamais utiliser incubateurs ou des getters dans l'init si la méthode est capable de fonctionner correctement dans ce scénario?

    InformationsquelleAutor user1864957