Поскольку общий экземпляр синглтона всегда будет рядом, можем ли мы безопасно использовать [unowned self] во всех замыканиях в этом классе синглтона?
Безопасно ли всегда использовать [unowned self] для синглетонов Swift?
Ответы (2)
Конечно, это безопасно. Но это не уважительная причина.
Используете ли вы слабые или сильные ссылки, это должно основываться на характеристиках управления памятью в функции, которую вы пишете. Например, если на замыкание строго ссылается объект, то замыкание должно фиксировать слабую ссылку на объект; и это безопасно, поскольку ни у кого больше нет ссылки на закрытие, поэтому оно может выполняться только тогда, когда основной объект жив и т. д. Если нет цикла сохранения, а закрытие передается отдельному API, чтобы оно не было привязано к времени существования основного объекта, то замыкание должно иметь сильную ссылку на основной объект. Это рассуждение в равной степени применимо как к синглтонам, так и к несинглетам.
person
newacct
schedule
29.05.2015
Да, синглтон содержит сильную ссылку на себя и не может быть удален.
На основании этого можно с уверенностью сказать, что вы можете безопасно создавать слабые или бесхозные ссылки на него.
Класс лениво создает свой единственный экземпляр при первом запросе и после этого гарантирует, что никакой другой экземпляр не может быть создан. Одноэлементный класс также не позволяет вызывающим объектам копировать, сохранять или освобождать экземпляр.
Простой способ проверить это — протестировать из основного класса.
- Создайте новый класс (назовем его «первый класс»), который инициализирует синглтон некоторыми значениями и удаляется после завершения уникальной работы.
- После этого в основном классе создайте еще один класс (назовем его «второй класс»), который извлекает экземпляр синглтона и считывает его значения.
Между первым (утилизированным) классом и вторым (вновь созданным) классом нет ссылок на синглтон.
- Теперь прочитайте значения, и если значения все еще существуют, это доказывает, что синглтон сохранил свою собственную ссылку.
person
Icaro
schedule
29.05.2015
В этой документации описываются соглашения, используемые для синглетонов Objective-C, а не какие-либо языковые гарантии для синглетонов Swift.
- person algal; 29.05.2015
Нет, если синглтон определяется как дизайнерский шаблон, попробуйте найти ссылку на любой язык на этой странице.
- person Icaro; 29.05.2015
Конечно, на этой странице нет ссылок на какой-либо язык. Но есть ссылки на многочисленные классы, реализованные в Objective-C, и весь контекст этого документа состоит в описании шаблонов Cocoa, поэтому я предполагаю, что обсуждение поведения сохранения счетчика не предназначено для описания какого-либо языка, кроме Objective-C. Но, возможно, я слишком много предполагаю!
- person algal; 29.05.2015
Это просто пример классов, которые используют этот дизайн, я добавляю простой тест в ответ, это определенно тест на то, что я говорю, если вы хотите попробовать. В любом случае, просто надеюсь, что я добавлю несколько ответов, а не больше вопросов.
- person Icaro; 29.05.2015
Извините, не пытаюсь быть троллем. Я думаю, вы правы в том, что можно безопасно ссылаться на экземпляр singleton как
unowned во всех замыканиях. Но я не думаю, что синглтон Swift автоматически запрещает вызывающим сторонам копировать, сохранять или освобождать этот экземпляр, поскольку это будет зависеть от того, как реализованы copy и другие методы. Кроме того, я не уверен, что экземпляр содержит сильную ссылку на самого себя. Но, честно говоря, я не уверен, что сохраняет синглтон в Swift, если он реализован, например, как глобальная переменная.
- person algal; 29.05.2015
Да, синглтон содержит сильную ссылку на себя. Я никогда не видел синглтона, который содержит сильную ссылку на самого себя.
- person newacct; 30.05.2015
