Почему у класса нет стандартного инициализатора?

Почему у класса может отсутствовать стандартный инициализатор

В Objective-C и Swift отсутствие стандартного (или автоматически сгенерированного) инициализатора у класса обычно связано с явным определением пользовательских инициализаторов, которые "переопределяют" поведение по умолчанию. Рассмотрим детально причины, актуальные для обоих языков, с упором на современный Swift.

1. Swift: Переопределение стандартного инициализатора init()

В Swift, если вы не определяете никаких инициализаторов, компилятор автоматически предоставляет стандартный инициализатор (init()) для классов, у которых все свойства имеют значения по умолчанию. Однако, как только вы объявляете хотя бы один пользовательский инициализатор, компилятор перестаёт генерировать стандартный init(). Это называется подавлением стандартного инициализатора.

class Person {
    var name: String = "Unknown" // Свойство имеет значение по умолчанию
    var age: Int = 0             // Свойство имеет значение по умолчанию
    
    // Автоматически генерируется init() ✅
}

let person1 = Person() // Работает, используется стандартный инициализатор.

class Employee {
    var name: String
    var department: String
    
    // Пользовательский инициализатор
    init(name: String, department: String) {
        self.name = name
        self.department = department
    }
    
    // Стандартный init() НЕ генерируется ❌
}

// let emp = Employee() // Ошибка компиляции: 'Employee' cannot be constructed because it has no accessible initializers
let emp = Employee(name: "Alice", department: "IT") // Только так

Причина: Когда вы явно задаёте способ инициализации через пользовательский инициализатор, компилятор предполагает, что вы хотите полный контроль над процессом. Автоматический init() мог бы создать объект в неконсистентном состоянии, если для корректной работы требуются определённые параметры.

2. Наличие свойств без значений по умолчанию (в Swift)

Для структур (struct) в Swift правило иное — они всегда получают почленный инициализатор (memberwise initializer), если не объявлены свои. Но для классов отсутствие значений по умолчанию у всех stored-свойств требует обязательного определения пользовательского инициализатора. Стандартный init() не может быть сгенерирован, так как он не знал бы, какими значениями инициализировать такие свойства.

class Vehicle {
    let numberOfWheels: Int // Константа без значения по умолчанию
    
    // Компилятор НЕ сгенерирует init().
    // Требуется явно определить инициализатор:
    init(wheels: Int) {
        self.numberOfWheels = wheels
    }
}

3. Наследование и инициализаторы в Swift

В иерархии наследования делегирование инициализаторов подчиняется строгим правилам:

• Назначенный инициализатор (designated initializer) должен вызвать назначенный инициализатор суперкласса.
• Если подкласс не определяет ни одного назначенного инициализатора, он автоматически наследует все назначенные инициализаторы суперкласса (при выполнении условий: все свойства подкласса имеют значения по умолчанию и подкласс не переопределяет инициализаторы суперкласса).
• Если подкласс определяет все назначенные инициализаторы суперкласса (либо через наследование, либо через переопределение), он автоматически наследует все его convenience-инициализаторы.

Если суперкласс не имеет доступного (например, private) стандартного init(), то и подкласс его не унаследует.

class SuperClass {
    let id: Int
    init(id: Int) { self.id = id } // Только один назначенный инициализатор
    convenience init() { self.init(id: 0) } // Convenience-инициализатор
}

class SubClass: SuperClass {
    var title: String = "Default"
    // Не определяем своих инициализаторов.
    // Условия выполнены -> наследуем ВСЕ инициализаторы суперкласса.
}

let obj1 = SubClass()      // Наследуется convenience init() ✅
let obj2 = SubClass(id: 5) // Наследуется init(id:) ✅

Если бы SuperClass не имел convenience init(), а только init(id:), то у SubClass также не было бы стандартного init().

4. Objective-C: Явное объявление init или NS_DESIGNATED_INITIALIZER

В Objective-C ситуация исторически более гибкая, но с появлением nullability annotations и NS_DESIGNATED_INITIALIZER стала строже.

• Традиционно, если класс не объявлял явно init, он часто наследовал его от суперкласса NSObject ([NSObject init]).
• Однако, современные best practices требуют явно объявлять designated initializer с макросом NS_DESIGNATED_INITIALIZER. При этом:

    *   Все другие инициализаторы должны быть помечены как `NS_UNAVAILABLE` или быть **secondary**.
    *   Компилятор (и статические анализаторы) предупредят, если designated initializer суперкласса не будет вызван.

• Если вы объявляете свой designated initializer и не предоставляете реализацию стандартного init, он становится недоступным.

// Objective-C
@interface MyModel : NSObject

@property (nonatomic, copy, readonly) NSString *identifier;

- (instancetype)initWithIdentifier:(NSString *)identifier NS_DESIGNATED_INITIALIZER;
- (instancetype)init NS_UNAVAILABLE; // Явно запрещаем стандартный инициализатор

@end

@implementation MyModel

- (instancetype)initWithIdentifier:(NSString *)identifier {
    self = [super init];
    if (self) {
        _identifier = [identifier copy];
    }
    return self;
}

@end

// MyModel *model = [[MyModel alloc] init]; // Ошибка компиляции: 'init' is unavailable

Ключевые выводы

• Основная причина — явное объявление пользовательских инициализаторов в Swift, которое отключает генерацию init().
• Цель — обеспечение целостности объекта. Класс обязывает использовать инициализаторы, которые гарантируют установку всех необходимых свойств в валидное состояние.
• В Swift правила чётко формализованы и зависят от наличия значений по умолчанию у свойств и иерархии наследования.
• В Objective-C отсутствие стандартного init — часто результат сознательного проектного решения (использование NS_UNAVAILABLE, NS_DESIGNATED_INITIALIZER) для обеспечения корректной инициализации и улучшения безопасности API.
• Практический совет: Всегда явно инициализируйте stored-свойства классов и продумывайте набор инициализаторов как часть публичного API вашего типа, запрещая (с помощью private или unavailable) те, которые могут привести объект в неконсистентное состояние.