Objective-C klasa konwencja nazewnictwa vs Wujek Bob

Question

W Chapter 2: Meaningful Names Uncle Bob pisze:

Nie Dodaj nieodpłatnych kontekst

w wyimaginowanej aplikacji o nazwie "Gas Station Deluxe", to jest złe pomysł na prefiks każdej klasy z GDS. Szczerze mówiąc, pracujesz przeciwko swoim narzędziom. Wpisujesz G i naciśnij klawisz zakończenia i są nagradzani listy mil długości każdej klasy w systemie

Właściwie to, co odkryłem podczas moich pierwszych dni z Objective-C, nieco ponad rok temu. Po Jawie było to dość rozczarowujące, ale myślałem, że jestem tylko tym, który denerwuje się tym :) Rozumiem, że książka "Czysty kod" odnosi się do Javy przez większość czasu, a Java ma przestrzenie nazw (pakiety) w przeciwieństwie do Objective-C.

Czy używasz prefiksu 2-3 liter w swoich zajęciach, jeśli tworzysz aplikację, a nie bibliotekę? Co myślisz, czy to zły projekt językowy, "funkcja" językowa czy wujek Bob nie był tutaj?

Answer 1

Być może kluczowym słowem jest tutaj nieodpłatne. W Objective-C przedrostki służą ważnemu celowi zmniejszenia prawdopodobieństwa kolizji nazw. W innych językach, takich jak Java i C++, istnienie wsparcia dla przestrzeni nazw sprawia, że ​​używanie przedrostków jest nieodpłatne (i naruszenie często cytowanej zasady DRY). W Objective-C prefiksy są jednak znaczące, użyteczne i nie są bezpłatne.

Answer 2

Osobiście prawie nigdy nie używam prefiksów. Jedynymi wyjątkami są klasy, które są ze sobą w jakiś sposób połączone lub wszystkie powinny być obecne.

Przykład:

Aplikacja kliencka do czatu. Nazwijmy ten czat jako ExampleChat.

Następnie używałbym ECMessage, ECUser, ECRoom itp., Aby łatwo zobaczyć, które klasy powinny być.

Jeśli tworzę niestandardowe komórki dla UITableView, użyłbym prefiksów, aby zachować je wszystkie blisko siebie i nie walczyć z przeszukiwaniem ich na "liście milowej". Przykład:

ECTextMessageCell, ECSoundMessageCell, ECUploadMessageCell, ECJoinOrLeaveMessageCell itp

To moja osobista opinia, która nie może być najlepszym. Ale nadal jest to dla mnie najłatwiejsze.

Nadzieja pomaga

Answer 3

Więc jeśli nie masz Przestrzenie nazw, konflikty nazw są prawdopodobne. Możesz zauważyć, że w wielu bibliotekach C używają one pewnego rodzaju prefiksu. Sądzę więc, że istnieją dobre powody, by mieć te prefiksy i inne powody, aby tego nie używać. Ale jaki powinien być duży problem z modyfikacją ukończenia, aby po prostu zignorować prefiks wpisywania trzech liter, a nie tylko jednego.

W końcu wydaje mi się, że to kwestia gustu. Sądzę, że ważniejsze byłoby mieć dobre klasy struktur z prefiksami zamiast bałaganu bez prefiksu ...

Nie ma to nic wspólnego z projektowaniem w języku niemieckim IMHO. Był czas, w którym oprogramowanie nie było wszędzie i dlaczego warto marnować dodatkowy wysiłek na przestrzeń nazw? I nadal widzimy, że w dzisiejszych czasach używane są języki bez przestrzeni nazw .....

Answer 4

Powiedziałbym, że świat nie jest czarny ani biały.Robię programowanie w Javie, z pakietami i tak, denerwowanie ma prefiks w każdej klasie, a także irytujące i dyskusyjne jest uruchamianie interfejsów z I (podobnie jak .Net używane do tego).

Czasami denerwuje mnie to w celu-c, ale ma pewną legitymację, jeśli nie masz pakietów w swoim języku, ponieważ możesz "budować" sztuczne grupy klas, takie jak "NS", "UI", "MK" i tak dalej w objc i kakao.

Answer 5

Kusiło mnie, aby zamknąć to pytanie, ale nie sądzę, że widziałem wcześniej podobne pytanie i jest to ważne pytanie. Oto moje raczej niezorganizowane przemyślenia na ten temat.

Wiele języków ma funkcję o nazwie namespaces, gdzie nazwa klasy "w pełni kwalifikowana" jest poprzedzana hierarchiczną serią nazw. Na przykład klasa String w języku Java to odpowiednio java.lang.String, a klasa niestandardowa jest odpowiednio com.whatever.foobar.MyClass.

Niestety, przestrzenie nazw nigdy nie zostały dodane do Objective-C, co oznacza, że ​​symbole Objective-C (nazwy klas, nazwy protokołów i kilka innych typów) nie mogą być umieszczane w przestrzeni nazw nawet przy użyciu Objective-C++ (który ma funkcję przestrzeni nazw dla funkcji, stałych, struktur itp.).

Jedynym rozwiązaniem, które zapobiega kolizji symboli w kodzie wspólnym, jest użycie jakiejś formy wymieszania nazw, aby nazwy unikalnych symboli były niepowtarzalne. W Objective-C konwencja polega na użyciu przedrostka dwóch znaków (czasami ich liczba jest różna) dla wszystkich klas.

Ten wujek Bob jest twitem, który mówi ci, żeby tego nie robić, ponieważ podczas gdy skończysz z programem, który się nie kompiluje, stracisz wszelkie korzyści z przestrzeni nazw, które wciąż oferują prefiksy. Czy Twoja aplikacja używa wtyczek? Musisz przedrostkiem. Czy Twoja aplikacja ma publiczny interfejs API? Musisz przedrostkiem.

Teoretycznie kod w pojedynczej aplikacji, która nigdy nie styka się ze światem zewnętrznym, może obejść się bez prefiksów, ale przykręć go - zachowaj czysto kodowanie i dodaj tam nawet prefiks. Zaoszczędzi ci to później żalu.

Answer 6

Oprócz unikania kolizji, jedną z korzyści, jakie daje nazwa przedrostków, jest natychmiastowe zdawanie sobie sprawy z tego, z jakim typem mamy do czynienia. Załóżmy, że następujący kod:

Color c = ...; 
MultiValueMap m = ...; 

Od Rzut oka na kod i biblioteki w zależności od tego, co już używane, te typy mogą być z wielu różnych źródeł. Być może będziesz musiał sprawdzić, które z instrukcji include/import zostało wykonane, aby zrozumieć, co może zrobić typ (np. Chcesz go zmodyfikować, ale brakuje w nim pewnej metody, na którą masz pewność).

W świecie iOS od razu wiadomo, czy jest to UIColor vs. CGColor i zyskuje bezpośredni kontekst.

W przeszłości na konferencji WWDC firma Apple przeprowadzała sesję, w której wyjaśniała konwencje kodowania Cocoa/Objective-C. Wydaje mi się, że wspominają ten aspekt prefiksów nazw, więc możesz chcieć znaleźć jedno z nagrań, które zostały udostępnione. Inni twórcy C (np.Programiści jądra Linuksa) również nie wydają się wysoko myśleć o obszarach nazw C++ (wśród innych funkcji C++) z różnych powodów.