Инициализация класса

initialize метод класса дает Вам место для имения некоторого кода, выполняемого один раз, лениво, прежде чем будет вызван любой другой метод класса. Это обычно используется для установки номеров версий классов (см. Управление версиями и Совместимость).

Время выполнения отправляет initialize к каждому классу в цепочке наследования, даже если это не реализовало его; таким образом это могло бы вызвать класс initialize метод несколько раз (если, например, подкласс не реализовал его). Обычно Вы хотите, чтобы код инициализации был выполнен только один раз. Один способ гарантировать это происходит, должен использовать dispatch_once():

+ (void)initialize {

    static dispatch_once_t onceToken = 0;

    dispatch_once(&onceToken, ^{

        // the initializing code

    }

}

Вы никогда не должны вызывать initialize метод явно. Если необходимо инициировать инициализацию, вызовите некоторый безопасный метод, например:

[NSImage self];

Определяемые инициализаторы

Определяемый инициализатор init метод класса, вызывающего init метод суперкласса. (Другие инициализаторы вызывают init методы определяются классом.) Каждый общедоступный класс должен иметь один или несколько определяемые инициализаторы. Как примеры определяемых инициализаторов там NSView initWithFrame: и NSResponder init метод. Где init методы не предназначены, чтобы быть переопределенными, как имеет место с NSString и другие абстрактные классы, выходящие на кластеры класса, подкласс, как ожидают, реализует свое собственное.

Определяемые инициализаторы должны быть ясно идентифицированы, потому что эта информация важна для тех, кто хочет разделить Ваш класс на подклассы. Подкласс может просто переопределить определяемый инициализатор, и все другие инициализаторы будут работать, как разработано.

При реализации класса платформы часто необходимо реализовывать ее методы архивации также: initWithCoder: и encodeWithCoder:. Бойтесь делать вещи в пути выполнения кода инициализации, не происходящем, когда разархивирован объект. Хороший способ достигнуть этого состоит в том, чтобы вызвать общую подпрограмму от Ваших определяемых инициализаторов и initWithCoder: (который является самим определяемым инициализатором), если Ваш класс реализует архивацию.

Обнаружение ошибок во время инициализации

Хорошо разработанный метод инициализации должен завершить следующие шаги для обеспечения надлежащего обнаружения и распространения ошибок:

1. Повторно присвойтесь сам путем вызова superопределяемый инициализатор.

2. Проверьте возвращенное значение на nil, который указывает, что некоторая ошибка произошла в инициализации суперкласса.

3. Если ошибка происходит при инициализации текущего класса выпустите объект и возврат nil.

Перечисление 1 иллюстрирует, как Вы могли бы сделать это.

  Обнаружение ошибок перечисления 1 во время инициализации

- (id)init {

    self = [super init];  // Call a designated initializer here.

    if (self != nil) {

        // Initialize object  ...

        if (someError) {

            [self release];

            self = nil;

        }

    }

    return self;

}

Версия платформы

Когда присутствие новой функции или исправления ошибки не легко обнаруживаемо с тестами во время выполнения, необходимо предоставить разработчикам некоторый способ проверить на изменение. Один способ достигнуть этого состоит в том, чтобы сохранить точный номер версии платформы и сделать это число доступным для разработчиков:

• Задокументируйте изменение (в информации о версии, например) под номером версии.

• Определите номер текущей версии своей платформы и обеспечьте некоторый способ сделать его глобально доступным. Вы могли бы сохранить номер версии в информационном списке свойств своей платформы (Info.plist) и доступ это оттуда.

Включенная архивация

Если объекты Вашей платформы должны быть записаны в файл пера, они должны быть в состоянии заархивировать себя. Также необходимо заархивировать любые документы, использующие механизмы архивации, чтобы хранить данные документа.

Необходимо рассмотреть следующие проблемы об архивации:

• Если ключ будет отсутствовать в архиве, то просить его значения возвратится nil, NULL, NO, 0, или 0.0, в зависимости от типа, попросившего относительно. Тест для этого возвращаемого значения для сокращения данных, которые Вы выписываете. Кроме того, можно узнать, был ли ключ записан в архив.

• Оба кодировать и декодирует методы, могут сделать вещи гарантировать назад совместимость. Например, закодировать метод новой версии класса мог бы записать новые ключи использования значений, но может все еще выписать более старые поля так, чтобы более старые версии класса могли все еще понять объект. Кроме того, декодируйте методы, мог бы хотеть иметь дело с отсутствующими значениями некоторым разумным способом поддержать некоторую гибкость для будущих версий.

• Рекомендуемое соглашение о присвоении имен для архивных ключей для классов платформы состоит в том, чтобы начаться с префикса, используемого для других элементов API платформы, и затем использовать имя переменной экземпляра. Просто удостоверьтесь, что имена не могут конфликтовать с именами никакого суперкласса или подкласса.

• Если у Вас есть служебная функция, выписывающая тип исходных данных (другими словами, значение, которое не является объектом), несомненно, будут использовать уникальный ключ. Например, если у Вас есть «archiveRect» подпрограмма, архивирующая прямоугольник, должен взять ключевой аргумент и любое использование это; или, если это выписывает многократные значения (например, четыре плавания), это должно добавить свои собственные уникальные биты к предоставленному ключу.

• Архивация битовых полей как есть может быть опасной вследствие зависимостей от порядка байтов и компилятора. Необходимо заархивировать их только, когда по причинам производительности много битов должно быть выписано много раз. Посмотрите Битовые поля для предложения.

Постоянные данные

По причинам производительности хорошо отметить как постоянное как можно больше данных платформы, потому что выполнение так сокращает размер __DATA сегмент Мужественного двоичного файла. Глобальные и статические данные, которые не являются const заканчивается в __DATA раздел __DATA сегмент. Этот вид данных приводит память в рабочее состояние в каждом рабочем экземпляре приложения, использующего платформу. Несмотря на то, что дополнительные 500 байтов (например), не могли бы казаться настолько плохими, это могло бы вызвать инкремент в числе требуемых страниц — дополнительные четыре килобайта за приложение.

Необходимо отметить любые данные, которые являются постоянными как const. Если существует нет char * указатели в блоке, это заставит данные приземляться в __TEXT сегмент (который делает его действительно постоянным); иначе это останется дома __DATA сегмент, но не будет записан на (если предварительная привязка не будет сделана или нарушена при необходимости двигать двоичный файл во время загрузки).

Необходимо инициализировать статические переменные, чтобы гарантировать, что они объединяются в __data раздел __DATA сегмент в противоположность __bss раздел. Если нет никакого очевидного значения для использования для инициализации, используйте 0, NULL, 0.0, или независимо от того, что является надлежащим.

Битовые поля

Используя значения со знаком для битовых полей, особенно одноразрядных битовых полей, может привести к неопределенному поведению, если код предполагает, что значение является булевской переменной. Одноразрядные битовые поля должны всегда быть без знака. Поскольку единственные значения, которые могут быть сохранены в таком битовом поле, 0 и-1 (в зависимости от реализации компилятора), сравнивание этого битового поля к 1 является ложью. Например, если Вы сталкиваетесь с чем-то вроде этого в своем коде:

BOOL isAttachment:1;

int startTracking:1;

Необходимо изменить тип на unsigned int.

Другая проблема с битовыми полями архивирует. В целом Вы не должны писать битовые поля в диск или архивы в форме, в которой они находятся, поскольку формат мог бы отличаться, когда они читаются снова на другой архитектуре, или на другом компиляторе.

Выделение памяти

В коде платформы лучший курс должен избежать выделять память в целом, если можно помочь ему. При необходимости во временном буфере по некоторым причинам обычно лучше использовать штабель, чем выделить буфер. Однако штабель ограничивается в размере (обычно 512 килобайтов в целом), таким образом, решение использовать штабель зависит от функции и размера буфера, Вам нужно. Обычно, если размер буфера составляет 1 000 байтов (или MAXPATHLEN) или меньше, использование штабеля приемлемо.

Одно улучшение должно начаться с помощью штабеля, но переключиться на a malloc’редактор буферизует, если требования размера идут вне размера буфера штабеля. Перечисление 2 представляет фрагмент кода, делающий просто что:

  Выделение перечисления 2 с помощью и штабеля и буфера malloc’ed

#define STACKBUFSIZE (1000 / sizeof(YourElementType))

 YourElementType stackBuffer[STACKBUFSIZE];

 YourElementType *buf = stackBuffer;

 int capacity = STACKBUFSIZE;  // In terms of YourElementType

 int numElements = 0;  // In terms of YourElementType

while (1) {

    if (numElements > capacity) {  // Need more room

        int newCapacity = capacity * 2;  // Or whatever your growth algorithm is

        if (buf == stackBuffer) {  // Previously using stack; switch to allocated memory

            buf = malloc(newCapacity * sizeof(YourElementType));

            memmove(buf, stackBuffer, capacity * sizeof(YourElementType));

        } else {  // Was already using malloc; simply realloc

            buf = realloc(buf, newCapacity * sizeof(YourElementType));

        }

        capacity = newCapacity;

    }

    // ... use buf; increment numElements ...

  }

  // ...

  if (buf != stackBuffer) free(buf);