extension для типов

1. Зачем нам extension, если у типов уже есть методы?

Когда вы только начинаете писать код, кажется, что всё просто: объявили struct, написали свойства, тут же добавили методы — и поехали. Но как только тип становится чуть «живее» (например, у книги появляется форматирование, поиск, валидация, удобные утилиты), объявление раздувается. В какой-то момент ваш struct Book превращается в свиток, который нужно листать как древний манускрипт, и вы начинаете мечтать о телепорте к нужному методу.

И вот тут появляется extension — один из самых «швейцарских ножей» Swift. Он позволяет расширять существующий тип: добавлять к нему методы (и не только), не меняя исходное объявление и не прибегая к наследованию.

Важно сразу поймать мысль: extension — это не «создать новый тип». Это буквально «вот этому типу добавим ещё пару возможностей».

Ментальная модель: тот же тип, просто дописанный сбоку

Представьте, что тип — это дом. Сначала вы построили коробку: стены, крыша, двери (stored properties, init). Потом решили добавить веранду и пару полок. Можно снести дом и перестроить — а можно аккуратно пристроить. extension — это как раз пристройка: дом тот же, адрес тот же, но возможностей больше.

Технически компилятор Swift воспринимает это так: все extension для типа “склеиваются” с основным объявлением, и в итоге у типа появляется единый набор методов.

Небольшая схема:

flowchart TD
    A["struct Book { ... }<br/>данные + базовые вещи"] --> C["Итоговый Book API"]
    B["extension Book { ... }<br/>удобные методы"] --> C
    D["extension Book { ... }<br/>ещё методы"] --> C

То есть в коде это может быть несколько блоков, а в голове (и в API) — один тип.

Базовый синтаксис extension Type { ... }

Синтаксис предельно простой: вы пишете extension, затем имя типа, затем фигурные скобки. Внутри — методы.

Пример: расширяем стандартный тип Int

import Foundation

extension Int {
    func squared() -> Int {
        self * self
    }
}

print(7.squared()) // 49

Здесь важны две детали.

Во‑первых, self внутри метода — это «текущее значение». Если у нас 7.squared(), то self внутри squared() равен 7.

Во‑вторых, мы добавили метод к стандартному типу, то есть сделали Int удобнее под нашу задачу. Это очень типичный стиль Swift: маленькие расширения, которые читаются как «естественный язык».

Небольшое правило хорошего вкуса

Когда вы умеете расширять Int, возникает опасное искушение: «а давайте добавим Int.isMoodGoodToday()». Компилятор, конечно, не против. Но ваш будущий коллега (или вы через два месяца) будет против — и довольно громко.

Хороший extension обычно добавляет то, что:

1. логически относится к типу;
2. не требует нового состояния (потому что stored properties добавлять нельзя — об этом поговорим ниже);
3. улучшает читаемость кода.

Пример: более «прикладной» метод

import Foundation

extension Int {
    func clamped(to range: ClosedRange<Int>) -> Int {
        if self < range.lowerBound { return range.lowerBound }
        if self > range.upperBound { return range.upperBound }
        return self
    }
}

print(15.clamped(to: 0...10)) // 10
print((-3).clamped(to: 0...10)) // 0

Метод читается почти как фраза: «15, ограничься диапазоном 0…10».

2. Мини‑приложение: библиотека книг

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

Сделаем базовую модель книги максимально простой: только данные. Без «умностей».

Пример: Book как контейнер данных

import Foundation

struct Book {
    let id: Int
    var title: String
    var author: String
    var year: Int
    var isRead: Bool
}

Пока это просто коробка с полями. И это нормально: данные отдельно — поведение можно пристроить через extension.

Форматирование вывода

Теперь представим, что мы хотим печатать книгу в консоль аккуратно и одинаково. Можно каждый раз писать строковую интерполяцию руками, но это быстро превращается в кашу. Гораздо приятнее, когда сама книга «умеет» представиться.

Пример: метод форматирования

import Foundation

extension Book {
    func shortLine() -> String {
        let mark = isRead ? "✓" : "•"
        return "\(mark) \(title) — \(author), \(year)"
    }
}

Обратите внимание: метод не меняет книгу, он только вычисляет строку. Значит, mutating не нужен.

Мини‑использование

import Foundation

var b = Book(id: 1, title: "Swift Basics", author: "Apple", year: 2024, isRead: false)
print(b.shortLine()) // • Swift Basics — Apple, 2024

Методы, которые меняют состояние

Очень частый вопрос новичков: «если метод в extension, нужно ли mutating?». Ответ: да, правила те же. extension не «обходит законы физики» Swift.

Если метод меняет stored properties структуры, он должен быть mutating.

Пример: переключаем флаг прочитанности

import Foundation

extension Book {
    mutating func toggleRead() {
        isRead.toggle()
    }
}

Мини‑использование

import Foundation

var b = Book(id: 2, title: "Algorithms", author: "Knuth", year: 1973, isRead: false)
b.toggleRead()
print(b.isRead) // true

Здесь удобно то, что «как переключать» спрятано внутри типа. В основном коде мы не думаем про детали: просто говорим книге «переключись».

Поиск по запросу

В реальных консольных задачах часто нужно искать по строке: пользователь вводит запрос, а мы показываем подходящие книги. Логика сравнения может быть чуть сложнее, чем contains: например, мы хотим игнорировать регистр и лишние пробелы.

Пока мы не изучаем regex и сложный парсинг, сделаем простой и предсказуемый вариант: нормализуем строку через trimmingCharacters и lowercased() и сравниваем.

Пример: расширяем String методом нормализации

import Foundation

extension String {
    func normalized() -> String {
        self.trimmingCharacters(in: .whitespacesAndNewlines).lowercased()
    }
}

Теперь добавим к Book метод, который проверяет, подходит ли книга под запрос.

Пример: поиск по названию и автору

import Foundation

extension Book {
    func matches(query: String) -> Bool {
        let q = query.normalized()
        if q.isEmpty { return true }

        return title.normalized().contains(q) || author.normalized().contains(q)
    }
}

Смотрите, как читается: «книга matches запрос».

3. Ограничения extension

Когда extension начинает нравиться, хочется использовать его как «рюкзак без дна». Но у расширений есть жёсткие правила — и они спасают проект от хаоса.

Нельзя добавлять stored properties

extension не может изменить «форму памяти» типа. Если бы можно было добавлять stored properties, возник бы вопрос: где они хранятся, как инициализируются, что будет с уже существующими экземплярами типа. Это ломало бы половину языка.

Поэтому в extension нельзя писать так (и компилятор вам не даст):

// ❌ Не скомпилируется
// extension Book {
//     var rating: Int = 0
// }

Если нужно хранение — оно должно быть в основном объявлении struct.

Нельзя объявить второй метод с той же сигнатурой

Если у типа уже есть метод с такой же сигнатурой, попытка объявить второй такой же — конфликт. Это защита от случайной подмены поведения.

И да: extension — это не override. Наследование и переопределение — отдельная история, и мы туда сейчас не лезем.

Доступ к private в extensions

На практике Swift позволяет организовывать код так, чтобы private‑члены типа были доступны и в его extension, если всё это находится в одном исходном файле. Это сделано специально, чтобы расширения были удобным инструментом организации кода, а не причиной постоянно писать fileprivate.

Мы пока не углубляемся в уровни доступа (это отдельный большой разговор), но полезно знать, что extensions — это не «чужой код», а нормальная часть типа.

4. Как оформлять extension, чтобы не устроить свалку

Когда вы освоили extension, следующий уровень — не технический, а человеческий: как разложить код так, чтобы его было приятно читать.

Представьте, что вы открываете файл и видите:

extension Book { /* 40 методов */ }

Это почти то же самое, что запихнуть 40 методов в struct Book { }. Смысл теряется.

Хорошая практика — делать несколько extension‑блоков, каждый со своей «темой». Например:

• один extension — форматирование строк;
• второй extension — логика поиска;
• третий extension — операции изменения состояния (mutating).

Пример: несколько extension подряд — это нормально

import Foundation

extension Book {
    func shortLine() -> String {
        "\(title) — \(author)"
    }
}

extension Book {
    func matches(query: String) -> Bool {
        title.lowercased().contains(query.lowercased())
    }
}

extension Book {
    mutating func toggleRead() {
        isRead.toggle()
    }
}

С точки зрения компилятора это один и тот же тип. А с точки зрения человека — код разложен по полочкам.

Мини‑сборка в одном файле

Соберём маленький сценарий, который показывает, зачем всё это было: мы создаём массив книг, печатаем их, затем фильтруем по запросу.

Пример: демонстрация поведения

import Foundation

// Модель
struct Book {
    let id: Int
    var title: String
    var author: String
    var year: Int
    var isRead: Bool
}

// Расширения
extension String {
    func normalized() -> String {
        self.trimmingCharacters(in: .whitespacesAndNewlines).lowercased()
    }
}

extension Book {
    func shortLine() -> String {
        let mark = isRead ? "✓" : "•"
        return "\(mark) \(title) — \(author), \(year)"
    }
}

extension Book {
    func matches(query: String) -> Bool {
        let q = query.normalized()
        if q.isEmpty { return true }
        return title.normalized().contains(q) || author.normalized().contains(q)
    }
}

// Сценарий
var library: [Book] = [
    Book(id: 1, title: "Swift Basics", author: "Apple", year: 2024, isRead: false),
    Book(id: 2, title: "The Swift Programming Language", author: "Apple", year: 2023, isRead: true),
    Book(id: 3, title: "Clean Code", author: "Robert C. Martin", year: 2008, isRead: false)
]

let query = "apple"

for book in library where book.matches(query: query) {
    print(book.shortLine())
}
// • Swift Basics — Apple, 2024
// ✓ The Swift Programming Language — Apple, 2023

Заметьте, как изменилось ощущение от кода. В «сценарии» мы почти не видим низкоуровневых деталей. Мы читаем: «книга подходит под запрос», «выведи короткую строку». Это и есть главная победа extension: он помогает говорить кодом на языке предметной области.

5. Типичные ошибки

Ошибка №1: воспринимать extension как способ «добавить поля» к типу.
Новички часто пытаются объявить в extension новое stored property, потому что «ну мне же надо где-то хранить рейтинг/кэш/счётчик». Swift запрещает это не из вредности: расширение не меняет layout памяти типа. Если нужно хранение, добавляйте stored property в основной struct, а в extension оставляйте поведение и вычисления.

Ошибка №2: забыть mutating в extension у struct.
Иногда кажется, что «extension — это что-то отдельное», и правила struct как будто не действуют. Действуют. Если метод меняет isRead, title или любое другое stored property, нужен mutating, иначе компилятор не даст вам «случайно» испортить value‑семантику.

Ошибка №3: устроить в одном extension «комбайн на все случаи жизни».
Технически можно сделать один огромный блок extension Book и писать туда всё подряд: печать, поиск, изменение состояния, какие-нибудь вычисления. Но читаемость упадёт почти сразу. Гораздо спокойнее мозгу (и будущей поддержке) несколько коротких extension‑блоков, каждый по смыслу.

Ошибка №4: конфликт имён с существующим API.
Если вы расширяете стандартные типы (String, Int) и называете методы слишком общо (например, format() или trim()), легко случайно пересечься с существующим API или ввести коллег в заблуждение. Выбирайте имена, которые ясно отражают смысл, и не стесняйтесь делать их чуть длиннее ради читабельности.

Ошибка №5: добавлять методы, которые «не принадлежат» типу по смыслу.
Можно расширить Int чем угодно, но это не значит, что так надо. Если метод не описывает естественное поведение типа, лучше вынести его в функцию или в отдельный помощник‑тип. Иначе вы получите код, где у чисел внезапно появляются «бизнес‑способности», и это выглядит так, будто ваш проект тихо уезжает в сюрреализм.