Xcode generuje teraz pustą kategorię. Czemu?

Question

Zauważyłem to podczas używania iOS6 beta 3

Kiedy tworzę nową podklasę UIViewContoller (żadne inne klasy rodziców nie generują tego zachowania, które zauważyłem), plik .m ma teraz pustą kategorię na górze pliku. W przeszłości, gdy uczyłem się o kategoriach, zauważyłem, że niektórzy ludzie używaliby tej samej techniki do wskazania prywatnych metod (choć nie prawdziwie prywatnych).

Czy to jest cel? Czy nastąpiła jakakolwiek zmiana, która sprawiała, że ​​rzeczy rzeczywiście są teraz prywatne? Zauważyłem także dyrektywę @private.

Jaki jest styl kodowania osoby w odniesieniu do prywatnych przypadków i metod?

AKTUALIZACJA: Ponieważ XCode zachęca nas do używania rozszerzeń klas, zastosowałem je dla prywatnych metod/ivar dla tego projektu. Znalazłem jednak wadę. Widziałem, że mogę ponownie użyć jednego z moich subklasowanych UIViewControllers wraz z wszystkimi jego UIButtons, UILabels, etc .... Miałem to dziedziczenie: UIViewController < - FirstViewController < - SecondViewController.

Cóż, wszystkie prywatne metody, które umieszczam w rozszerzeniu klasy FirstViewController, nie pojawiają się w autouzupełnianiu, gdy koduję w SecondViewController. Lekki kłopot ....

Answer 1

Teraz odnosząc się do tej definicji interfejsu:

@interface MYViewController() 
@end 

To jest technicznie rozszerzenie klasy zamiast kategorii. Kategorie zawierają ciąg w nawiasach. Rozszerzenia klasy są dodawane do klasy w czasie kompilacji, więc mogą dodawać ivars (zwykle w postaci właściwości). Kategorie są dodawane w czasie wykonywania i nie mogą dodawać znaków iv.

Wszystko, co powiedzieliśmy, twoja uwaga jest prawidłowa. Służy do definiowania prywatnych metod i właściwości.

W świecie ObjC "prywatny" to znak "zakaz wstępu", a nie ściana z drutu brzytwego. Chociaż istnieje słowo kluczowe @private (które dodaje wymuszenie kompilatora), dotyczy to tylko ivars i generalnie nie jest konieczne. Ten rodzaj prywatności opartej na ostrzeżeniach działa bardzo dobrze w ObjC i jest dość wystarczający.

Umieść swoje prywatne właściwości w tym rozszerzeniu klasy, a rozmówcy zewnętrzni otrzymają ostrzeżenia "mogą nie odpowiadać na selektor", jeśli spróbują uzyskać do nich dostęp (tak, jak mogliby uzyskać wywołanie dowolnej niezdefiniowanej metody). Nigdy nie należy zezwalać na istnienie ostrzeżeń w projekcie ObjC, co wymusza hermetyzację danych.

---

EDIT

Jeśli są prywatne, to powinny one nie pojawiają się w Twojej podklasy. To, czego chcesz, jest chronione. W ObjC nie ma świetnego schematu dla metod chronionych, ale powszechną techniką jest umieszczanie ich w kategorii w pliku .h, takim jak MYViewController + Protected.h. Uważam, że pojawia się to bardzo rzadko w praktyce, ponieważ tyle dobrego projektu ObjC nie ma podklasy. Zamiast tego używa kompozycji i delegacji.

Odnośnie "Po prostu zobacz kontrolerów." Po pierwsze, to nie tylko kontrolery widoku. To tylko kontrolery widoku na iOS (dobrze, VC, TableViewController i GLKViewController). Na Macu to także kontrolery okien i importery spotlightów.Zajrzyj:

.../Developer/Platforms/iPhoneOS.platform/Developer/Library/Xcode/Templates 
.../Library/Xcode/Templates 

Ale dlaczego te? Cóż, to są kontrolery, a kontrolerzy potrzebują prywatnej własności. W rzeczywistości, jeśli nie masz prywatnych właściwości w kontrolerze, prawdopodobnie robisz zbyt dużo publicznych. To nie jest tak uniwersalne dla klas modelu i widoku. Podejrzewam, że zagrał w ich decyzji. Mogą to być również inne osoby, które posiadały szablony lub które były aktualizowane w różnym czasie. Czasami widzisz małe niespójności, które z czasem wygładzają się.

Można również tworzyć własne szablony. Zobacz Creating Custom Xcode 4 File Templates.