Zła praktyka zachowania "ja"?

Question

Mam proste zapytanie, które chciałbym wyjaśnić komuś ... Czy to jest złe praktyki, aby zachować siebie?

Mam obiekt żądania serwera, który chciałbym utworzyć. Chciałbym, aby móc używać go w następujący sposób:

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

Aby obiektu nie do samounicestwienia, jak tylko pula autorelease jest odprowadzana, wyobrażam sobie, muszę zadzwonić do zatrzymywania w jego metoda init, a następnie wydanie po otrzymaniu, przetworzeniu i dostarczeniu odpowiedzi serwera do jej delegata.

Jednak coś podnoszą ostrzegawczy dzwonek w mojej głowie z tym podejściem. Lepsze sposoby na zrobienie tego?

Answer 1

Nie ma nic złego w zachowaniu self, o ile zostanie zwolniony w jakimś dobrze zdefiniowanym punkcie zgodnie z normalnym protokołem zarządzania pamięcią. Jeśli obiekt musi istnieć, dopóki nie zostanie spełniony jakiś warunek, powinien wziąć za to odpowiedzialność, tak jak robi to za każdy inny obiekt, którego wymaga, aby kontynuować.

Przedstawianie w przeciwnym razie obcych obiektów menedżerskich lub wyrzucanie odpowiedzialności na właściciela obiektu z przesądnych powodów byłoby tutaj prawdziwym anty-wzorem.

(odpowiednik podejście na śmieci zgromadzone w kodzie byłaby dla obiektu, aby wykluczyć się od zbierania śmieci, podczas gdy wyniki są w toku, lub korzeń go poprzez zbiór jakiejś jeśli nie podoba się ten pomysł.)

Answer 2

Najprostszym sposobem, aby to zrobić, jest utworzenie iVar dla twojego żądania, zachowanie żądania po uruchomieniu i zwolnienie go po wywołaniu ostatniej metody delegatów.

Czy ARequest to klasa, którą stworzyłeś? Czy tworzy nowy wątek, aby asynchronicznie przesłać żądanie?

Answer 3

Raz zrobiłam to samo, co ty. Napisałem metodę kategorii na NSString, aby wysłać ją do serwera, który ją wydrukuje. W metodzie kategorii musiałem zadzwonić pod numer [self retain], aby metody wywołania zwrotnego mogły być metodą NSString-Categroy.
Czułem się tak źle, że przepisałem wszystko na Singleton, do którego dostęp ma metoda Category. Tak więc Singleton zachowa sznur tak długo, jak będzie to konieczne.

Answer 4

Nie jest to niesłychane, ale jest dość rzadkie. Głównym sposobem, w jaki go widziałem (i użyłem go sam), jest sytuacja, w której mamy do czynienia z jakimś obiektem półsynchronicznym (przez pół-synchroniczne oznacza to, że nie blokuje on głównego wątku, ale także nie wykonać na wątku tła, NSURLConnection pasuje do tego rachunku). Na przykład napisałem podklasę o nazwie NSWindowController, która służyła do wyświetlania okna jako arkusza i do wywoływania niektórych delegowań odbierających. Zasadniczo chcesz alloc/init nowy kontroler arkusza i wywołać beginSheetForWindow:. Powoduje to, że arkusz będzie pół-synchroniczny, a następnie wywoła odpowiednie wywołanie zwrotne, gdy arkusz zostanie zwolniony.

Ponieważ obiekt wywołujący niekoniecznie "jest właścicielem" arkusza (pomyśl o tym, że jest to wersja kontrolera modalnego na systemie iOS), kontroler arkusza wykonuje natychmiast [self retain] natychmiast po wyświetleniu arkusza, a następnie [self release] natychmiast po wyczyszczeniu i wywoływanie wywołań zwrotnych. Celem tego było upewnienie się, że obiekt będzie się trzymał, dopóki arkusz nie zostanie wykonany. (Arkusz, IIRC, został zatrzymany przez pętlę, ale potrzebowałem również kontrolera, aby się trzymać)

Tak jak powiedziałem, bardzo rzadko można spotkać się z sytuacją, w której chciałbyś [self retain], ale nie jest to niemożliwe. Jednak zgodnie z ogólną zasadą, jeśli uważasz, że musisz [self retain], możesz pomyśleć jeszcze raz.