Как меняется контракт протокола после добавления ограничения AnyObject?
Ограничение AnyObject делает протокол классовым: ему могут соответствовать только экземпляры классов, но не структуры, перечисления или другие типы-значения. Благодаря этому значение такого протокола гарантированно имеет ссылочную семантику, поэтому его можно использовать, например, в weak-ссылке.
В Swift протоколы по умолчанию могут реализовываться как типами-значениями, так и ссылочными типами. Это удобно для универсальных абстракций, но не подходит для контрактов, которым требуется объектная семантика: общий жизненный цикл, идентичность экземпляра или слабая ссылка.
Ограничение AnyObject позволяет явно выразить такое требование на уровне типа. Исходная проблема — не допустить реализацию протокола структурой там, где код ожидает именно объект класса.
Представим делегат, который хранится слабо, чтобы не образовать цикл сильных ссылок. Для структуры понятие слабой ссылки неприменимо: структура копируется как значение и не управляется ARC как экземпляр класса.
Если протокол делегата не ограничен AnyObject, компилятор не может гарантировать, что любое его значение является объектом. Поэтому объявление слабого свойства через такой протокол будет недопустимым, пока протокол не станет классовым.
Запись protocol Delegate: AnyObject означает: соответствовать Delegate могут только классы. Класс может одновременно быть ссылочным типом и реализовывать этот протокол; структура или перечисление получат ошибку компиляции при попытке соответствия.
Классовое ограничение не добавляет автоматически наследование, методы или свойства. Оно только сужает множество допустимых conforming-типов и позволяет использовать свойства ссылочной семантики там, где это поддерживается языком.
В частности, значение классового протокола можно хранить в weak-свойстве:
После того как у Owner не останется сильных ссылок, ARC освободит экземпляр, а cache.owner автоматически станет nil. Такая модель невозможна для протокола, который может быть реализован структурой.
Ограничение не означает, что все значения протокола можно сравнивать оператором идентичности ===: для этого нужны подходящие операнды ссылочного типа, а не только общий факт классового ограничения. Также AnyObject не запрещает классу быть final, наследоваться или содержать свойства-значения.
Главный компромисс — потеря универсальности. Классовый протокол нельзя применить к структуре или перечислению, даже если их поведение полностью подходит контракту. Поэтому AnyObject следует добавлять только тогда, когда ссылочная семантика действительно является частью требований дизайна.
В UIKit-подобном компоненте Cache хранит владельца или делегата, который не должен продлевать жизнь самого кэша. Если объявить обычный протокол без AnyObject, слабое свойство не сможет безопасно выразить это требование: потенциальный conforming-тип может оказаться структурой.
Вариант с сильной ссылкой формально работает для классов, но способен создать цикл удержания и задержать освобождение объектов. Вариант с неограниченным протоколом сохраняет универсальность для структур, однако не позволяет гарантировать объектную семантику.
Выбранное решение — ограничить протокол AnyObject и хранить зависимость слабо. Контракт становится честным: делегат обязан быть объектом, его время жизни контролируется сильными владельцами, а кэш не удерживает делегата. Цена решения — невозможность реализовать этот протокол структурой.
Можно ли ограничить AnyObject уже после появления реализаций протокола?
Нет, это меняет контракт протокола. Типы-значения, ранее соответствовавшие такому протоколу, больше не смогут ему соответствовать. Ограничение нужно проектировать как часть исходного API, если ссылочная семантика обязательна.
Делает ли AnyObject все свойства и методы протокола ссылочными по поведению?
Нет. AnyObject ограничивает только типы, которые могут соответствовать протоколу. Внутри класса по-прежнему могут быть свойства-значения, а методы могут изменять или заменять их. Классовое ограничение не превращает отдельные свойства в ссылки и не меняет правила let и var.
Почему классовое ограничение важно для делегатов, но не обязательно для любого протокола сервисов?
Делегат обычно представляет конкретного долгоживущего участника взаимодействия: важны его идентичность, состояние и контролируемый жизненный цикл. Для чистого сервиса, который не хранится слабо и не требует идентичности, структура может быть предпочтительнее благодаря семантике значения и отсутствию ARC. Поэтому AnyObject следует использовать не как общий признак «объектного API», а только как явное требование ссылочной семантики.