2013-04-12 4 views
1

Я читаю «Руководство по программированию основных данных». Он содержит этот текст:реализация пользовательских методов доступа

You must, however, change attribute values in a KVC-compliant fashion. For example, the following typically represents a programming error:

NSMutableString *mutableString = [NSMutableString stringWithString:@"Stig"]; [newEmployee setFirstName:mutableString]; [mutableString setString:@"Laura"];

For mutable values, you should either transfer ownership of the value to Core Data, or implement custom accessor methods to always perform a copy. The previous example may not represent an error if the class representing the Employee entity declared the firstName property (copy) (or implemented a custom setFirstName: method that copied the new value). In this case, after the invocation of setString: (in the third code line) the value of firstName would then still be “Stig” and not “Laura”.

Вопрос о тексте: «В данном случае» есть что случай - один, где свойство объявляется как «копия» или когда его нет?

Вопрос относительно копирования и практике программирования: Из того, что я прочитал здесь: NSString property: copy or retain? Я понимаю

  1. , что использование копии гарантирует, что ПгвЬЫате является «Стиг», не Лаура
  2. разумно для этого, потому что «почти во всех случаях вы хотите предотвратить мутацию атрибутов объекта за его спиной»

Мне очень хотелось бы знать, что t - приведенный выше цитируемый текст, который пытается рассказать нам в контексте Core Data. В любом случае мы должны использовать «копию», используя Core Data или нет. Кроме того, я был бы рад, если бы кто-то мог пролить больше света на точку «2» (это разумно ...) выше, как в том, что будет последствиями изменения атрибутов объекта за его спиной?

ответ

0

Проблема в том, когда следует использовать (и как) неизменяемые значения.

Поскольку основные данные используют KVO при обнаружении изменений объектов, если вы используете изменяемое свойство, которое изменяется непосредственно через него, а не через свойство, CoreData не обнаружит изменения объекта, и ваши изменения могут не сохраняются в магазине.

Если вы используете измененные атрибуты NSManagedObject, переопределите метод setter/getter и используйте только их, чтобы мутировать базовый объект (это означает, что вы несете ответственность за то, чтобы CoreData знал, что с объектом произошло изменение, и оно должно сохраняются в хранилище.
Кроме того, если вы используете трансформируемые свойства для сложных объектов, вы должны инициировать уведомления об изменениях самостоятельно, чтобы CoreData осознал, что произошло изменение, и объект должен быть повторно преобразован и сохранен, когда контекст сохраняет.

Я бы очень рекомендовал, чтобы, когда дело доходит до простых объектов, таких как строки, вы используете значения неизменяемых свойств, которые заставят вас идти через свойства объекта и инициировать уведомление KVO по умолчанию (атрибуты копирования также заставят KVO-уведомления).

1

Ваш вопрос о тексте: «В этом случае» - это случай, когда объект объявлен как «копия» или когда его нет? » неправильно соответствует точке, которую Apple хочет объяснить, я считаю.

Как указано в документе Apple, если пользовательский метод доступа реализуется нормально, реализация по умолчанию NOT значения атрибута копирования. Если значение атрибута может быть изменчивым и реализует протокол NSCopying (например, в случае с NSString, например), вы можете скопировать значение в пользовательском аксессуре, чтобы помочь сохранить инкапсуляцию (, например, в случае, когда экземпляр NSMutableString передается как значение).

Вот копирование сеттер сниппет

@interface Department : NSManagedObject 
{ 
} 
@property(nonatomic, copy) NSString *name; 
@end 
@implementation Department 
@dynamic name; 
- (void)setName:(NSString *)newName 
{ 
    [self willChangeValueForKey:@"name"]; 
    // NSString implements NSCopying, so copy the attribute value 
    NSString *newNameCopy = [newName copy]; 
    [self setPrimitiveName:newNameCopy]; 
    [self didChangeValueForKey:@"name"]; 
} @end 
Смежные вопросы