2009-08-21 12 views
8

Zauważyłem, że większość programów kodujących Objective-C nigdy nie używa składni self->ivar przy bezpośrednim dostępie do zmiennych instancji. Większość przykładowego kodu, który widzę, po prostu odwołuje się do zmiennej instancji bez self->. Sądzę, że pomylenie zmiennej instancji jest dość mylące, nie wyjaśniając, że jest to zmienna instancji, a nie tylko zmienna bieżącego zakresu.Używanie self-> ivar do bezpośredniego dostępu do zmiennych instancji

czuję, że chcę pisać rzeczy jak:

- (void)dealloc { 
    [self->someVar release]; 
    [self->anotherVar release]; 
    [super dealloc]; 
} 

lub

- (void)setVar:(Foo *)newVar { 
    [self->var autorelease]; 
    self->var = [newVar retain]; 
} 

Nie ma dużo okazjach, kiedy nigdy nawet powinny uzyskać dostęp do naszych zmiennych instancji bez użycia accessor do enkapsulacji, ale czasami potrzebujemy takich jak dealloc, lub w niestandardowych programach pobierających i ustawiających.

Czy jestem złą osobą/programistą do robienia tego? Czy istnieje jakiś naprawdę dobry powód, by nie pisać takiego kodu? Ponieważ naprawdę dobrze jest robić to w ten sposób.

Odpowiedz

7

Chuck jest poprawny, ponieważ nie powinieneś pisać tego w ten sposób, chyba że shadowujesz ivars ze zmiennymi lokalnymi, co jest generalnie złym pomysłem. Jednak można argumentować, że pomijanie stylu jest czystsze stylistycznie i na pewno skutkuje mniej obszernym kodem. Osobiście uważam, że self-> może rozpraszać uwagę (zwłaszcza jeśli kod jest dobrze zaprojektowany, a zmienne są dobrze nazwane), ale jeśli sprawia to, że są bardziej zrozumiałe dla ciebie, zrób to. Pamiętaj, że jeśli pokażesz swój kod innym programistom Objective-C, prawdopodobnie będą mieć sprzeczne opinie, więc dobrze jest mieć przemyślaną skórę. Poza tym, większość programistów uważa, że ​​ich postrzeganie tego, co sprawia, że ​​kod "czuje się dobrze" zmienia się z czasem iz doświadczeniem, a te opinie często łagodzą z wiekiem. :-)

+2

Tak jak powiedziałem, jest krótszy. Wolę to, ale nie mogłem argumentować, że krótsze identyfikatory są zawsze lepsze - nie chciałbym utrzymywać kodu, który jest wszystkim X, Y i Z. Więc to w zasadzie kwestia, gdzie znajdujesz swoje szczęśliwe medium. Podejrzewam, że Pythoniści prawdopodobnie woleliby formę 'self->'. Oczywiście, nie powinieneś często wykonywać bezpośredniego dostępu do ivar w Objective-C. Być może bycie nieatrakcyjnym to kolejna zaleta składni "self->". – Chuck

+0

Lol. "pomyśl o skórze". Czy ta skóra jest cienka i trochę gruba? – Rob

7

Nie ma powodu, dla którego nie powinieneś pisać tego w ten sposób. Myślę, że ludzie zazwyczaj piszą to w inny sposób, ponieważ starają się unikać shadowingu swoich ivars, więc nie powinno być żadnych dwuznaczności w jakiej zmiennej mówią - i jest krótsza.

+0

Wielkie dzięki za szybką odpowiedź! –

4

Krótka odpowiedź: Nie, nie jesteś złym programistą z tego powodu :) Nie ma również powodu, by nie pisać kodu w ten sposób; większość programistów po prostu jest leniwych lub nigdy nie napisała wyczerpującej metody w całym swoim życiu.

Długa odpowiedź: Technicznie, gdy uzyskujesz dostęp do zmiennej bez "self->", kompilator najpierw będzie używał zmiennej o tej nazwie w zasięgu lokalnym, a jeśli jej nie znajdzie, powtórzy wyszukiwanie za pomocą zmiennych instancji. Jeśli znajdzie tam trafienie, wygeneruje kod tak, jakby zapisano tam "self -> ...". Jeśli nie ma dopasowania dla zmiennych instancji, kompilator spróbowałby w zasięgu globalnym, BTW.

Większość programistów czyta tylko własny kod i dobrze wie, czym jest zmienna instancji, a co nie. Kiedyś musiałeś pracować z kodem, którego sam nie napisałeś, gdzie metoda ma 4 strony ekranu (i mam duży ekran), jesteś naprawdę wdzięczny, gdy programista zrobił to absolutnie jasno na każdym dostępie zmiennym: czy ta zmienna jest parametr podawany do wywołania metody, lokalna zmienna tej metody, zmienna instancji obiektu lub ewentualnie zmienna globalna (tylko globalna dla wszystkich wystąpień tej klasy lub być może globalna aplikacja). Jesteś wdzięczny, ponieważ jeśli istnieje tylko kilka zmiennych o podobnej nazwie i bez specjalnego nazewnictwa lub wzorca dostępu, jakkolwiek różnią się one od siebie typem, dość szybko tracisz niedopatrzenie.Opieranie się na fakcie, że podświetlanie składni Xcode podświetla zmienne instancji w inny sposób niż zmienne lokalne, jest również głupie, ponieważ żaden programista nie jest zmuszony do edycji kodu w Xcode, a nawet jeśli to robi, może mieć schemat kolorów, w którym instancja zmienne są tego samego koloru co lokalne.

Uzyskiwanie dostępu do zmiennych instancji za pomocą self-> jest całkowicie poprawne, ale rozważ także możliwość użycia prefiksu/sufiksu, co również sprawi, że będą to zmienne instancji, a także uniknie konfliktów nazw z parametrami metody lub zmiennymi lokalnymi.

1

Obiekt C automatycznie dodaje znak podkreślenia do nazwy i-var, więc gdy widzisz "_someVar", jest to niejawny zasięg klasy. Podkreślenie jest wystarczającym znacznikiem wizualnym, aby jego zakres był jasny, bez dodawania self->.

+0

Zgadzam się z tobą, że jeśli zobaczysz '_someVar' wydane w' dealloc' lub ustawione w ustawiaczu, możesz być pewny, że to jest ivar. Ale gdybym zobaczył 'someVar' w tych kontekstach, prawdopodobnie założyłbym, że był to ivar, tylko ten, który został ręcznie zdefiniowany lub ręcznie zsyntetyzowany (z' @ synthesize'). Podsumowując, trudno powiedzieć, że wiodące '_' oznacza, że ​​jest" niejawnie "ivar. Podkreślenie nie jest warunkiem koniecznym ani wystarczającym. Ale masz rację, że najlepszą praktyką jest użycie właściwości, pozwól, aby ivars zostały zsyntetyzowane dla ciebie, i będą miały wiodący podkreślenie. – Rob

Powiązane problemy