Ответ.

История вопроса

В Swift с самого начала сделали акцент на value types — структуры (struct) как основной инструмент моделирования данных. В отличие от Objective-C, где всё было объектами (классами), Swift поощряет использование структур для простых моделей, данных и небольших бизнес-объектов.

Проблема

Многие разработчики, особенно с опытом других объектно-ориентированных языков, ошибочно используют классы для всего. Это ведет к проблемам с памятью (reference cycles), неожиданным изменениям при передаче объектов и сложностями с thread safety, ведь классы — reference types.

Решение

Структуры в Swift — value types, они копируются при присваивании и передаче в функции, в отличие от классов (reference types), которые передают ссылку. Именно это делает структуры предпочтительными для моделей без сложной логики жизненного цикла и наследования.

Пример кода:

struct Point {
    var x: Int
    var y: Int
}

var p1 = Point(x: 10, y: 20)
var p2 = p1
p2.x = 30
// p1.x остался равен 10

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

• Копирование структуры всегда вызывает копию значений (value semantics)
• Меньше возможностей утечек памяти
• Не поддерживают наследование, только протоколы

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

Можно ли у структуры быть наследник (subclass)?

Нет, структуры в Swift не поддерживают наследование. Всё расширение поведения возможно только через протоколы и extensions.

Означает ли, что структура всегда копируется при передаче в функцию?

На практике, Swift использует Copy-On-Write оптимизации. Если мы не меняем структуру, она не копируется, а копия создается только при изменении. Это касается стандартных коллекций и сложных структур.

var arr1 = [1, 2, 3]
var arr2 = arr1
arr2.append(4) // Только тут происходит копирование

В каких случаях нельзя использовать структуру?

• Если требуется identity (объектность, сравнение по ссылке)
• Если нужен наследник
• Если должен быть единственный экземпляр (singleton)

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

• Использование классов для простых моделей и структур данных
• Хранение ссылочных типов внутри структуры и попытка их копировать
• Ожидание передачи структуры "по ссылке" и попытка изменить внешний объект через структуру

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

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

Использовали классы для хранения однотипных данных (например, для точек на карте), как результат — потери производительности из-за частого обращения к памяти, сложное управление памятью и баги с перепутанными ссылками.

Плюсы:

• Возможность хранить в массиве как AnyObject

Минусы:

• Меньшая производительность
• Трудности с thread safety
• Проблемы с управлением памятью

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

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

Плюсы:

• Простота, безопасность копирования
• Отсутствие reference cycles
• Легко тестировать

Минусы:

• Нельзя реализовать паттерны, требующие наследования
• Если внутри структуры ссылочный тип — возможны сюрпризы при копировании и изменениях