Плохая практика сохранения «я»?

Question

У меня есть простой запрос, который я хотел бы прояснить кем-то ... Является ли плохой практикой сохранять себя?

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

ARequest *request = [ARequest request: someParam]; 
request.delegate = self; 
[request begin]; 

Для того, чтобы объект не самоуничтожение как только autorelease бассейн сливают, я полагаю, мне нужно назвать сохранить в его init, а затем выпуск после получения ответа сервера, обработки и доставки его делегату.

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

Answer 1

Нет ничего плохого в сохранении self, если вы отпустите его в некоторой четко определенной точке в соответствии с обычным протоколом управления памятью. Если объект требует, чтобы существовало до тех пор, пока не будет выполнено какое-либо условие, он должен взять на себя ответственность за это, так же как и для любого другого объекта, который требуется продолжить.

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

(Эквивалент подход сборки мусора код будет для объекта, чтобы исключить себя из сбора мусора в то время как результаты находятся на рассмотрении, или корень его через коллекцию какой-то, если вам не нравится эта идея.)

Answer 2

Самый простой способ сделать это - создать iVar для вашего запроса, сохранить запрос при его запуске и отпустить его при вызове последнего метода делегата.

ARequest класс, который вы создали? Создает ли он новый поток для асинхронного представления запроса?

Answer 3

Я однажды сделал то же самое, что и вы. Я написал Category-Method на NSString, чтобы отправить его на сервер, который будет его печатать. В методе категорий мне пришлось позвонить [self retain], чтобы методы обратного вызова могли быть NSString-Categroy-Method to.
Мне было так плохо, что я переписал все, чтобы использовать Singleton, к которому обращается метод Category. Таким образом, Singleton будет сохранять строку до тех пор, пока это необходимо.

Answer 4

Это не неслыханное, но это не редкость. Основной способ, которым я видел его использование (и использовал его сам), - это когда вы имеете дело с каким-то полусинхронным объектом (по полусинхронному я имею в виду, что он не блокирует основной поток, но он также не выполнить на фоновом потоке, NSURLConnection будет соответствовать этому счету). Например, я написал подкласс NSWindowController, который был специально предназначен для отображения окна в виде листа и для вызова некоторых определенных обратных вызовов делегатов. В принципе, вы должны были бы установить alloc/новый контроллер листа и вызвать beginSheetForWindow:. Это приведет к полусинхронизму листа, а затем вызовет соответствующий обратный вызов, когда лист будет отклонен.

Поскольку вызывающий объект не обязательно «владеет» листом (подумайте об этом как о версии для Mac в режиме просмотра модального вида на iOS), контроллер листа делает [self retain] непосредственно перед показом листа и [self release] сразу после очистки и обратные вызовы. Цель этого заключалась в том, чтобы обеспечить, чтобы объект оставался на месте, пока лист не был выполнен. (Лист, IIRC, был сохранен в runloop, но мне также нужен контроллер, чтобы придерживаться)

Как я уже сказал, очень редко встречается ситуация, когда вы захотите [self retain], но это не невозможно. Однако, как общее правило, если вы считаете, что вам нужно [self retain], вы можете подумать еще раз.