Что будет если все переменные сделать weak?

Опасность повсеместного использования weak

Если сделать все переменные weak, это приведет к катастрофическим последствиям для работы приложения. Переменные со слабыми ссылками (weak) не удерживают объекты в памяти — как только на объект перестают указывать сильные ссылки (strong), он немедленно уничтожается системой. Рассмотрим ключевые проблемы.

1. Немедленное уничтожение объектов

class User {
    var name: String
    init(name: String) { self.name = name }
    deinit { print("User уничтожен") }
}

func createUser() {
    weak var user = User(name: "Анна") // weak ссылка
    // Объект уничтожается сразу после создания,
    // так как нет strong ссылок
    print(user?.name) // Выведет: nil
}

2. Невозможность хранения состояния

class DataManager {
    weak var data: NSData? // Всегда будет nil
    // Данные не сохранятся в памяти
}

let manager = DataManager()
manager.data = NSData() // Данные уничтожатся сразу

3. Краш при обращении к свойствам

class ViewController: UIViewController {
    weak var label: UILabel? // Всегда nil
    
    override func viewDidLoad() {
        super.viewDidLoad()
        label = UILabel()
        label?.text = "Текст" // Не выполнится, label уже nil
    }
}

4. Нарушение работы коллекций

var weakArray: [weak SomeClass] = [] // Такой синтаксис невозможен
// Для weak ссылок в коллекциях нужны специальные обертки

5. Проблемы с вычисляемыми свойствами и методами

class Calculator {
    weak var processor: Processor?
    
    var result: Int {
        // processor всегда nil
        return processor?.calculate() ?? 0 // Всегда вернет 0
    }
}

Правильное использование weak

Слабые ссылки предназначены для решения конкретных проблем:

● Предотвращение retain cycles

class Parent {
    var child: Child?
}

class Child {
    weak var parent: Parent? // weak разрывает цикл
}

● Delegate pattern

protocol DataSourceDelegate: AnyObject {
    func dataDidUpdate()
}

class DataSource {
    weak var delegate: DataSourceDelegate? // weak обязательно!
}

● Closures с [weak self]

class NetworkService {
    func fetchData(completion: @escaping (Result) -> Void) {
        URLSession.shared.dataTask { [weak self] data, _, _ in
            guard let self = self else { return }
            // Работаем с self
        }.resume()
    }
}

Практические рекомендации

Когда использовать strong (по умолчанию):

• Владение объектом — когда текущий контекст должен владеть объектом
• Хранение данных — массивы, словари, кэши
• UI компоненты — UIView, UIViewController, если они часть иерархии
• Сервисы и менеджеры — объекты, живущие весь жизненный цикл приложения

Когда использовать weak:

• Делегаты и протоколы — всегда weak для AnyObject протоколов
• Родительские ссылки в иерархиях — чтобы избежать retain cycles
• Замыкания, захватывающие self — [weak self] для асинхронных операций
• Обратные ссылки — когда объект A владеет объектом B, а B ссылается на A

Когда использовать unowned:

• Гарантированно существующие объекты — когда время жизни объекта гарантированно превышает время жизни ссылки
• Оптимизация производительности — когда точно знаете, что объект не станет nil

Заключение

Использование weak для всех переменных — антипаттерн, который разрушает фундаментальную модель управления памятью в iOS. Swift и Objective-C полагаются на подсчет ссылок (ARC), где strong ссылки определяют время жизни объектов. Weak ссылки — специальный инструмент для решения проблем циклических ссылок, а не способ управления памятью по умолчанию.

Правильный подход — использовать strong ссылки везде, где требуется владение объектом, и применять weak только в конкретных случаях для предотвращения retain cycles. Это обеспечивает стабильную работу приложения и предсказуемое управление памятью.