Jakie są wady ustawienia każdej nieruchomości na silną?

Jako nowy programista dla systemu iOS, miałem dzisiaj mnóstwo robaków do naprawienia, kilka z nich było powiązanych ze mną przy użyciu słabych właściwości zamiast silnych.Jakie są wady ustawienia każdej nieruchomości na silną?

Zdaję sobie sprawę, że dobry programista nie miałby tego problemu i ustawiłby tylko właściwości, które muszą być silne, ale jednak w moich nowatorskich oczach nie rozumiem, dlaczego powinienem używać słabych, to tylko zwiększa ryzyko problemów.

Źródło

2013-12-12 Geesh_SO

Głosowanie w celu ponownego otwarcia. Nie sądzę, że zamknięcie tego jako duplikatu było dobrym wezwaniem: głównym problemem tego pytania jest * użycie * silnego lub słabego, podczas gdy centralnym problemem drugiego pytania jest * zachowanie * silnego vs. słaby. – dasblinkenlight

@dasblinkenlight Nie zmienia to faktu, że jest to niezarejestrowana ankieta. Nie należy go zamykać jako duplikatu, ale jako "zbyt szeroki". –

W ogóle, należy zdecydować pomiędzy weak, strong, assign i copy patrząc na relacje między klasą posiadającą właściwości i wartości tej nieruchomości, a także od rodzaju własności podjęcia.

Jeśli właściwość jest ustawiona jest prymitywny, użyj assign (lub nie stosować kwalifikator własności w ogóle)
Jeśli właściwość jest ustawiona jest skalar, niezmienny obiekt, użyj strong
Jeśli właściwość bycia zestaw jest skalarne, zmienny obiekt wdrażania protokołu NSCopying użyć copy
Jeśli właściwość jest ustawiona jest zmienny, a prawo własności jest przenoszone do obiektu, użyj strong
Jeśli właściwość jest ustawiona jest zmiennym obiektem implementującym protokół NSCopying, ale prawo własności pozostaje w stosunku do wywołującego, należy użyć copy
Jeśli ustawiana właściwość jest odwołaniem zwrotnym (tj. właściwość "to parent" w obiekcie "child"), użyj weak.

Koncepcja własności jest bardzo ważna w referencyjnych modelach zliczanych pamięci. Jest to główny czynnik decydujący o twojej decyzji. Musisz zdecydować, gdzie jest główny właściciel obiektu, i dać mu silne referencje. Jeśli własność jest wspólna dla grupy obiektów, daj wszystkim silną referencję.

Najtrudniejsza sytuacja to sytuacja, w której obiekty mogą się nawzajem, bezpośrednio lub pośrednio.W takim przypadku lepiej byłoby zastąpić "własność" słowem "wie o", dać wszystkim obiektom wspólny "top" właściciela, który "posiada" wszystkich i modelować relacje "wie o" z referencjami weak.

Źródło

2013-12-12 20:55:30 dasblinkenlight

To jest najlepsza odpowiedź. Ale jedno wyjaśnienie. Termin "skalar" oznacza dla mnie prosty, nieobiektowy typ danych, który zawiera wartość, np. Int, float, char itd. W tym celu używasz assign, ponieważ nie zarządzasz pamięcią dla nich. –

To jest słaba odpowiedź dla nowego programisty. Jeśli nie wiedzą, czy powinni zachować silne lub słabe referencje, z pewnością nie będą wiedzieli, jaka jest niezmienna wartość skalarna. – davbryn

Kolejny punkt: Jest jeszcze inny przypadek, o którym nie wspominasz: Współwłasność. Czasami w projekcie wiele obiektów może mieć przypisane odniesienie do tego samego obiektu. Przykład: program graficzny, który może tworzyć wykresy 2D i 3D tego samego obiektu funkcji. Oba rodzaje wykresów mogą wymagać posiadania obiektu formuły, który wykreślają. Obiekt formuły może być zmienny, a jeśli użytkownik zmieni formułę, chcesz, aby te zmiany pojawiły się na aktywnych wykresach, więc kopiowanie nie jest właściwym wyborem. –

-3

Zasada, której używam, to: jeśli obiekt zostanie zatrzymany gdzie indziej, użyj słabego. Największą rzeczą dla mnie jest użycie kreatora interfejsu. Jeśli masz numer IBOutlet, możesz go osłabić, ponieważ obiekt ten jest obsługiwany w programie budującym interfejs, a w pliku XIB są bardzo ważne, aby uzyskać prawo do celów zarządzania pamięcią:

Źródło

2013-12-12 20:51:58

Twoja reguła to bardzo zły pomysł. Coś powinno pozostać silnym odniesieniem, jeśli musi zachować uchwyt na obiekcie. Decyzja ta jest zwykle podejmowana bez zastanowienia się, czy cokolwiek innego ma silne odniesienie, czy nie. – rmaddy

-1 Nie polegaj na innych obiektach, aby zająć się zarządzaniem pamięcią. – Caleb

jest to w większości prawdziwe dla OS X, ale absolutnie nie jest dla iOS, gdzie członkostwo jest trochę obrócone. –

i strong.

strong zwiększy licznik odwołań do wskaźnika, a Ty powiesz, że jesteś właścicielem obiektu.

weak nie zwiększa licznika odwołań, a obiekt może potencjalnie zniknąć w dowolnym momencie. Jeśli masz cykliczną zależność, powinieneś użyć weak, aby uniknąć wycieku pamięci (dwa obiekty, które mają silne odniesienia do siebie, są zależnością cykliczną i te obiekty nigdy nie zostaną zwolnione).

Powinieneś zawsze myśleć o zarządzaniu pamięcią, ale dobrą zasadą jest, że właściwość powinna zawsze być strong, chyba że masz pewność, że jest ona przechowywana w innym miejscu. Wiele obiektów może mieć odniesienie strong do tego samego obiektu bez żadnych problemów, o ile nie występują odniesienia cykliczne.

Źródło

2013-12-12 20:52:12 driis

niektórych bardzo podstawowych zasad kciuka:

Jeśli obiekt ma trzymać się przynajmniej aż skończysz z nim iść z silnym

Jeśli można obsługiwać obiekt znika bez ranie cię zbyt źle (tzn. to rodzic, który cię stworzył, może być fajny, aby wiedzieć o, ale nie super ważne), następnie użyj słaby

jeśli nie jest to NSObject (to jest int, float bool lub inny typ pierwotny) użyj przypisać.

Źródło

2013-12-12 21:14:09 davbryn

Jakie są wady ustawienia każdej nieruchomości na silną?

Odpowiedz

Powiązane problemy