Ответ.

Extensions в Swift появились как средство расширения типов — как стандартных (например, String, Array), так и собственных, без необходимости создавать наследников или изменять оригинальный исходный код. Это позволяет добавлять новые методы, вычисляемые свойства, подписки на протоколы и даже конформность к протоколам, сохраняя читабельность и единую архитектуру кода.

Проблема возникает при чрезмерном или беспорядочном использовании extensions: можно легко потерять контроль над исходным поведением типов, возникнут пересечения имён, и сложнее отслеживать, откуда что приходит, особенно в больших проектах или при подключении сторонних библиотек.

Решение состоит в чёткой структуре, организации extensions по смысловым группам, явной документации и избегании конфликтов с существующими именами, а также при необходимости ограничении области действия (например, через fileprivate или internal).

Пример кода:

extension String {
    var isEmail: Bool {
        return self.contains("@") && self.contains(".")
    }
    func trimmed() -> String {
        return trimmingCharacters(in: .whitespacesAndNewlines)
    }
}

Ключевые особенности:

• Позволяет добавлять новые методы, свойства и конформность к протоколам без доступа к исходникам.
• Не поддерживает хранение новых stored properties — только вычисляемые и функции.
• Может быть ограничено по области видимости с помощью fileprivate/internal.

Вопросы с подвохом.

Можно ли добавить stored property через extension?

Нет, extension позволяет добавлять только вычисляемые свойства и методы. Хранимые свойства (stored properties) через extension добавить нельзя. Попробуйте — компилятор сразу выдаст ошибку.

Что произойдет, если в двух разных extension объявить методы с одинаковыми именами для одного типа в разных файлах?

Будет конфликт имён, причём Swift не сможет решить, какой из методов вызывать, и ошибка проявится на этапе компиляции.

Могут ли extensions реализовывать private методы, которые видны только внутри extension?

Да, если объявить метод с помощью private, он будет виден только внутри самого extension и того файла, в котором объявлен (если используется fileprivate).

extension Int {
    private func isEvenInternal() -> Bool {
        return self % 2 == 0
    }
    func publicCheckEven() -> Bool {
        return isEvenInternal()
    }
}

Типовые ошибки и анти-паттерны

• Анти-паттерн: Добавление большого количества разнотипных функций в один extension без логической группировки.
• Ошибка: Несоблюдение области применения (например, extension public для функции, использующей internal детали).
• Конфликты имён при работе с библиотеками или написании extension на один тип разными разработчиками, если не согласована область задач.

Пример из жизни

** Негативный кейс

В большом проекте к String добавляют через extension методы для всего — от валидации почты до парсинга JSON. Через год никто не может понять, что откуда берётся: методы пересекаются по названиям, кто-то добавляет новую функцию, не зная о старой, и ломает поведение дипендентов.

Плюсы:

• Быстро добавляются новые возможности, не трогая основной тип.

Минусы:

• Запутанность, дублирование, ошибки, непредсказуемое поведение, сложность в поддержке.

** Позитивный кейс

Команда использует extensions для логических групп: отдельный extension для валидации, отдельный — для форматирования, с приватными помощниками внутри. Все методы документированы, использование новых методов обсуждается, есть code review.

Плюсы:

• Четкая структура, лёгкая поддержка, модульность, код читаем и прозрачен.

Минусы:

• Требуется дисциплина и договорённость в команде, возможно, дополнительное время на ревью и структурирование.