Deklaracja Forward vs #import gdy instacji

Question

mam MyClassA który ma właściwość typu MyClassB

// 
// MyClassA.h 
// 

@interface MyClassA : NSObject 

@property (strong, nonatomic, readonly) MyClassB *myClassB; 

@end 

MyClassB ma właściwość myString.

// 
// MyClassB.h 
// 

@interface MyClassB : NSObject 

@property (copy, nonatomic, readonly) NSString *myString; 

@end 

mam MyClassC który potrzebuje dostępu myString w jego realizacji.

powinienem -

a) Forward stwierdzenie MyClassB w MyClassA.h i #import "MyClassB.h" w MyClassC.m

lub

b) #import MyClassB.h w MyClassA.h

Answer 1

W ogóle, należy przekierować zadeklarować z @class gdzie to możliwe w twoich plikach nagłówkowych. Prawdopodobnie nie chciałbyś tego zrobić, gdy dziedziczysz po super klasie lub deklarujesz zgodność protokołu, ponieważ kompilator musi wiedzieć, co dzieje się w tej klasie lub protokole.

Dla tego przykładu użyłbym @class dla wszystkich deklaracji właściwości w plikach nagłówkowych i #import MyClassB.h w pliku MyClassC.m. To pozwoli MyClassC wiedzieć o wszystkich właściwościach w MyClassB.

Answer 2

Patrząc na to z nieco innym kątem ... trzeba zdecydować, czy chcesz, aby świat naprawdę wiemy o myClassB będący własnością MyClassA. Na przykład, jeśli chcesz tylko reklamować, że myString, które można uzyskać przez MyClassA. To izoluje inne klasy od poznania podstawowej implementacji myString. Jeśli nie musisz ujawniać MyClassB, ukryj to przed "resztą świata".

W tym przypadku byś zmienił MyClassA.h następująco:

// 
// MyClassA.h 
// 

@interface MyClassA : NSObject 

@property (strong, nonatomic, readonly) NSString *myString; 

@end 

W MyClassA.m, należy wykonać następujące czynności.

// 
// MyClassA.m 
// 

#import "MyClassA.h" 
#import "MyClassB.h" 

@interface MyClassA() 

@property (strong, nonatomic) MyClassB *myClassB;; 

@end 

@implementation MyClassA 

// Other meaningful code omitted 

- (NSString *)myString { 
    return self.myClassB.myString; 
} 

@end 

Należy pamiętać, że to, co robiłem tutaj jest użycie anonimowego kategorię wewnętrznie definiować właściwości dla myClassB.

Kluczową sprawą jest to, czy ma sens, aby nie narażać innych osób na działanie MyClassB. Główną zaletą tego podejścia jest to, że Twój kod jest bardziej plastyczny. Powiedzmy, że myString otrzymuje inny sposób. Od zupełnie innej klasy lub innej metody. Kod, który musi zużywać myString jest immunizowany.

Jeśli musisz wystawić , możesz użyć @class zgodnie z zaleceniami Tylera powyżej lub #import MyClassB.h z MyClassA.h. Najlepsze praktyki zalecają przekazanie deklaracji @class. Ale czasami wygoda polegająca na tym, że nie trzeba pamiętać o zaimportowaniu wielu plików w pliku implementacyjnym, może wygrać. To twoja baza kodów, więc możesz wybrać, który z nich działa najlepiej dla Ciebie. Generalnie używam kombinacji tych dwóch.