делая одно свойство сильным, неатомным для target-c - PullRequest
Новая
       7

делая одно свойство сильным, неатомным для target-c

0 голосов
/ 27 февраля 2019

У меня есть приложение с несколькими представлениями, и я использую объект для отслеживания моего входа в систему.Мой User.h выглядит следующим образом 

@interface User : NSObject

@property (strong, nonatomic) NSDictionary *data;

@property (weak, nonatomic) NSString *uid;
@property (weak, nonatomic) NSString *firstName;
@property (weak, nonatomic) NSString *lastName;
@property (weak, nonatomic) NSString *dob;
@property (weak, nonatomic) NSString *gender;
@property (weak, nonatomic) NSString *avatarURL;
@property (assign, nonatomic) NSInteger status;

- (void)setPropertiesWith:(NSDictionary *)data;

А User.m выглядит так 

#import "User.h"

@implementation User
/*
 * set properties
 */
- (void)setPropertiesWith:(NSDictionary *)data{
    self.data = data;

    self.uid = self.data[@"uid"];
    self.firstName = self.data[@"firstName"];
    self.lastName = self.data[@"lastName"];
    self.dob = self.data[@"dob"];
    self.gender = self.data[@"gender"];
    self.status = [[self.data valueForKeyPath:@"status"] intValue];
    self.avatarURL = self.data[@"avatarURL"];
}

@end

У меня были слабые данные, но в одном из представлений они бы отображалисьnull - я думаю, что ARC выпустила его.Пожалуйста, поправьте меня, если я ошибаюсь.

У меня есть 2 вопроса:

  1. При такой настройке данные strong, а остальные свойства weak, существует ли потенциальный риск дляэтот?

  2. Должен ли я сделать данные иваром, а все остальное оставить как есть?

Нет никаких реальных причин (кроме моих плохих навыков в классе) для существования свойств.Я просто нашел это очень интересным и хотел понять, что происходит.

1 Ответ

0 голосов
/ 27 февраля 2019

Вы спросили:

  1. При этой настройке данные strong, а остальные свойства weak, существует ли потенциальный риск для этого?

Да, если вы nil dictionary, все ваши свойства, вероятно, станут nil, при условии, что у вас нет других сильных ссылок на них в других местах.

Должен ли я сделать данные иваром и оставить все как есть?

Я бы даже не сделал это иваром (если нет каких-то других требований для сохранения этого, что у вас есть)делится с нами).Это должна быть просто локальная переменная, и сделать ваши свойства copy (или strong).

Я бы предложил (а) избавиться от свойства NSDictionary и (б)делая свойства NSString равными copy (или strong), а не weak.Кроме того, вместо использования метода setPropertiesWith, я бы просто определил инициализатор: 

// User.h

@interface User : NSObject

@property (copy, nonatomic) NSString *uid;
@property (copy, nonatomic) NSString *firstName;
@property (copy, nonatomic) NSString *lastName;
@property (copy, nonatomic) NSString *dob;
@property (copy, nonatomic) NSString *gender;
@property (copy, nonatomic) NSString *avatarURL;
@property (assign, nonatomic) NSInteger status;

- (instancetype)initWithDictionary:(NSDictionary *)dictionary;

@end

И 

// User.m

@implementation User

- (instancetype)initWithDictionary:(NSDictionary *)dictionary {
    if ((self = [super init])) {
        self.uid       = dictionary[@"uid"];
        self.firstName = dictionary[@"firstName"];
        self.lastName  = dictionary[@"lastName"];
        self.dob       = dictionary[@"dob"];
        self.gender    = dictionary[@"gender"];
        self.status    = [dictionary[@"status"] intValue];
        self.avatarURL = dictionary[@"avatarURL"];
    }

    return self;
}

@end

И тогда вызывающая сторона сделает: 

User *user = [[User alloc] initWithDictionary:someDictionary];

Есть и другие уточнения, которые вы могли бы здесь рассмотреть (например, readonly открытый интерфейс, объявление обнуляемости, упрощенные обобщения в словаре и т. Д.), Но приведенное выше, вероятно, является хорошей отправной точкой.

Кстати, если вам интересно, почему я сделал эти copy вместо strong, мы просто хотим защитить себя на случай, если вызывающий объект передал NSMutableString (который является подклассом NSString) и случайно мутировалэто позже.Это немного более безопасно, немного более защитная схема.

...