Почему метод стоит сделать приватным в Swift
Что проверяют
Понимаете ли вы уровни доступа в Swift и умеете ли обосновать решение не удобством, а сужением поверхности типа. Вопрос часто задают, чтобы выяснить, как вы относитесь к тестам и рефакторингу.
Как отвечать
Смысл в том, что у типа есть контракт и есть способ его выполнения. Приватным делается всё, что относится ко второму: пока метод виден только внутри, его можно переименовать, разбить или выкинуть, не проверяя весь проект и не ломая чужой код. Публичным остаётся минимум, за который тип отвечает.
Второй довод сильнее первого: приватный метод не позовут в неподходящий момент. Если он корректен только после настройки зависимостей или только на главном потоке, закрытость превращает устное соглашение в проверку компилятора.
Полезно показать, что уровни доступа знакомы не по одному слову:
private: область объявления и расширения того же типа в этом же файле;fileprivate: весь файл целиком;internal: модуль, действует по умолчанию, поэтому без разбиения на модули это почти всё приложение;publicиopen: наружу, причём наследование и переопределение вне модуля разрешает толькоopen;private(set): чтение снаружи, запись изнутри, частый и аккуратный вариант для свойств.
Где спотыкаются
Описывают private как «доступно только внутри класса» по памяти из других языков. В Swift он покрывает и расширения того же типа в том же файле, а «только внутри файла» это fileprivate, и на собеседовании эти два слова путают постоянно.
Ослабляют доступ ради тестов. @testable import поднимает видимость internal, но до private не дотягивается, и делать метод открытым только для проверки не нужно: тестируется поведение через публичный интерфейс, а метод, который очень хочется проверить отдельно, обычно просится в самостоятельный тип.
Считают, что закрытость даёт защиту в рантайме. Наследник NSObject с пометкой @objc остаётся вызываемым по селектору, а свойства достаются через KVC. Модификаторы доступа это дисциплина на этапе компиляции, не механизм безопасности.