Какая у вас хорошая репутация?

Question

Слабые и неопубликованные ссылки используются для предотвращения циклов удержания в ситуации, когда два объекта содержат ссылку на другую. Я использую слабый, но я не использую unowned. Вот пример Apple, ситуации, когда один из двух объектов следует использовать бесхозный ссылка:

class Customer { 
    let name: String 
    var card: CreditCard? 
    init(name: String) { self.name = name } 
} 

class CreditCard { 
    let number: UInt64 
    unowned let customer: Customer 
    init(number: UInt64, customer: Customer) { 
     self.number = number 
     self.customer = customer 
    } 
} 

Идея заключается в том, что кредитная карта не может существовать без клиента. Поэтому кредитная карта может обойтись без дополнительной развертки, которая повлечет за собой использование слабых ссылок, и вместо этого может использовать неопубликованную ссылку. Хммм ... так почему бы не использовать сильную ссылку? Если все другие ссылки на клиента должны были уйти (что не должно произойти?), То использование кредитной карты принадлежащей им справки приведет к краху; в то время как использование сильной ссылки приведет к утечке памяти. А? Выбор между двумя зол? Лучше сбой, потому что это скорее всего будет замечено во время разработки и тестирования?

Пожалуйста, помогите с некоторым пониманием. Благодарю.

Answer 1

Это на самом деле не проблема, потому что, как он стоит, то unowned ссылка не создает какое-либо сильный опорный цикл. Когда объект Customer будет освобожден, его CreditCard будет немедленно освобожден. У вашего CreditCard никогда не будет возможности ссылаться на освобожденный Customer.

Answer 2

Быстрый поиск по этой теме revelead this ссылка на другой ответ.

В основном weak ссылки могут или не могут быть nil, где, как unowned ссылки предположить, что она никогда не будет nil.

Подробнее об этом можно узнать на странице Apple docs.

Я предполагаю, что аргументация в пользу использования unowned в этом случае заключается исключительно в том, что считается, что unowned никогда не будет nil (без заказчика).

Answer 3

Лучше, чтобы потерпеть крах, потому что это скорее всего будет замечено во время разработки и тестирования?

Да.

Ну, не совсем.

Идея заключается в том, что дизайна вашего приложения должен гарантировать, что ни CreditCard экземпляра не переживет это соответствующий Customer экземпляра. Когда вы используете unowned, вы доверяете, чтобы иметь дизайн в игре, который логически гарантирует выполнение без сбоев.

Теперь, почему кто-либо когда-либо использовал unowned над weak? Просто! unowned удаляет всю проблему с помощью Optional, и если вы знаете, что ваш экземпляр CreditCard будет никогда не имеет значения Customer экземпляра, тогда вы должны использовать unowned.

Answer 4

Очень интересный вопрос.Вот некоторые различия между слабыми и бесхозный Список литературы согласно Apple's documentation.

Слабые ссылки

Слабая ссылка является ссылкой, что не держит сильное влияние на экземпляре он относится, и поэтому не остановите ARC от утилизации ссылочного экземпляра. Такое поведение предотвращает ссылку из становится частью сильного опорного цикла.

Список литература

без владельца

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

ответить на ваш вопрос в:

weak может стать нулевым, тогда как unowned предполагается, никогда не станет нулевым, поэтому weak будет опциональным, где, как unowned не должен быть факультативным.

В этом случае Customer может иметь или не иметь CreditCard, но не должно быть CreditCard без Customer.

Answer 5

Хорошо, я, наконец, получить его:

1. Последнее упоминание Клиента (кроме кредитной карты) устанавливается в ноль.
2. ARC проверяет количество обращений Клиента:
3. Кредитная карта имеет сильную ссылку - счетчик ссылок клиента будет 1, поэтому ARC не освободит его. Результат - утечка памяти.
4. или, кредитная карта имеет неопубликованную ссылку - счетчик ссылок клиента будет 0, поэтому ARC освободит его. Это приведет к тому, что счетчик кредитных карт перейдет в 0, что приведет к его освобождению. Следовательно, у Кредитной карты никогда не будет возможности разыграть свою теперь нулевую неопубликованную ссылку. Результат - без сбоев.

Таким образом, если мы разработали наш код таким образом, что держатель контрольного (Creditcard) гарантированно будет освобождаться, когда объект ссылки (Заказчик) освобождаются, то мы имеем такой сценарий для чего без владельца ссылка была разработана.

Благодаря @Bob

Answer 6

unowned на самом деле гораздо лучше, чем weak, в тех ситуациях, когда это целесообразно (т.е. он уверен, что бесхозный объект не будет выходить из существования), потому что:

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

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