Кто держит сильной ссылкой Presenter в MVP?

Взаимосвязь Presenter и View в MVP

В архитектуре MVP (Model-View-Presenter) существует фундаментальное правило: View всегда держит слабую ссылку на Presenter, в то время как Presenter держит сильную ссылку на View. Это ключевое отличие от других паттернов, таких как MVVM, и предотвращает утечки памяти.

Кто владеет сильной ссылкой на Presenter?

Сильную ссылку на Presenter обычно держит объект, который создал и запустил сцену (экран). В iOS-разработке это чаще всего:

• Координатор (Router) в паттерне Coordinator
• Модель навигации (UINavigationController, UIWindow)
• Родительский модуль или контейнер (если Presenter вложенный)
• Сам ViewController (в упрощенных реализациях, но это считается антипаттерном)

Типичная реализация на Swift

// View (ViewController) держит WEAK ссылку
protocol MyViewProtocol: AnyObject {
    func updateUI(with data: String)
}

class MyViewController: UIViewController, MyViewProtocol {
    private weak var presenter: MyPresenterProtocol?
    
    func setPresenter(_ presenter: MyPresenterProtocol) {
        self.presenter = presenter
    }
    
    func updateUI(with data: String) {
        label.text = data
    }
}

// Presenter держит STRONG ссылку на View
protocol MyPresenterProtocol {
    func viewDidLoad()
}

class MyPresenter: MyPresenterProtocol {
    private var view: MyViewProtocol?
    private let service: MyService
    
    init(view: MyViewProtocol, service: MyService) {
        self.view = view
        self.service = service
    }
    
    func viewDidLoad() {
        service.fetchData { [weak self] result in
            self?.view?.updateUI(with: result)
        }
    }
}

// Координатор создает и удерживает Presenter
class AppCoordinator {
    private var presenters: [String: Any] = [:] // Хранилище сильных ссылок
    private let navigationController: UINavigationController
    
    func showMyScreen() {
        let viewController = MyViewController()
        let service = MyService()
        let presenter = MyPresenter(view: viewController, service: service)
        
        // View получает weak ссылку
        viewController.setPresenter(presenter)
        
        // Координатор держит сильную ссылку
        presenters["MyScreen"] = presenter
        
        navigationController.pushViewController(viewController, animated: true)
    }
}

Почему такая схема важна?

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

   • View → weak → Presenter ← strong ← Координатор
   • При уничтожении View Presenter остается живым (удерживается координатором)
   • При уничтожении Координатора освобождается Presenter, затем View

2. Жизненный цикл Presenter

   • Presenter живет дольше, чем View
   • Может переживать пересоздание View (например, при повороте экрана)
   • Может управлять состоянием до/после отображения View

3. Тестируемость

   • Presenter легко тестируется без реального View
   • Можно создавать mock-объекты View
   • Presenter не зависит от жизненного цикла UIKit

Распространенные ошибки

// ❌ НЕПРАВИЛЬНО: View держит сильную ссылку
class WrongViewController: UIViewController {
    private var presenter: MyPresenterProtocol? // Сильная ссылка!
    // Теперь есть retain cycle, если Presenter держит strong ссылку на View
}

// ❌ НЕПРАВИЛЬНО: Presenter держит weak ссылку на сервисы
class WrongPresenter {
    private weak var service: MyServiceProtocol? // Сервис может быть освобожден раньше времени
}

Лучшие практики

• Всегда используйте weak для ссылки от View к Presenter
• Держите сильную ссылку на Presenter в координаторе или роутере
• Освобождайте Presenter при закрытии экрана (координатор удаляет его из хранилища)
• Для сложных сценариев используйте дизайн по контрактам (протоколы)
• В Presenter используйте capture lists ([weak self]) при работе с асинхронными вызовами

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