NSString: isEqual vs. isEqualToString

Jaka jest różnica między isEqual:i isEqualToString:?

Dlaczego klasy dodają metody isEqualTo * (isEqualToArray dla NSArray, isEqualToData dla NSData, ...) zamiast tylko nadpisywać isEqual:?

isEqual:porównuje ciąg z obiektem i zwróci wartość, NOjeśli obiekt nie jest łańcuchem. isEqualToString:jest szybsze, jeśli wiesz, że oba obiekty są ciągami znaków, zgodnie z dokumentacją :

Uwagi specjalne

Gdy wiesz, że oba obiekty są łańcuchami, ta metoda jest szybszym sposobem sprawdzenia równości niż isEqual:.

isEqualTo<Class>służy do zapewnienia określonych kontroli równości. Na przykład; isEqualToArray:sprawdza, czy tablice zawierają taką samą liczbę obiektów i czy obiekty o podanym indeksie wracają YESdo isEqual:testu.

Ponadto, w przypadku pisania własnych metod -isEqual:i -isEqualTo<Class>:metod, konwencją jest dopuszczenie zerowych argumentów dla -isEqual:i zgłoszenie wyjątku dla zerowych argumentów do-isEqualTo<Class>:

Moje przypuszczenie jest to, że zapewnia lekką poprawę wydajności, jak isEqualToString: nie będzie trzeba wpisywać-czek, co przeszedł w.

Poszerzanie wiedzy na @Abizern i @Jonathan Dann odpowiada zarówno na pytania, jak isEquali na isEqualToStringpracę z nilwartościami.

- (void)testStringEqual {
    NSString *string = nil;

    STAssertFalse([string isEqual:@"test"], @"NSString isEqual");
    STAssertFalse([string isEqualToString:@"test"], @"NSString isEqualToString");

    // Note that these both return NO
    STAssertFalse([string isEqual:nil], @"NSString isEqual");
    STAssertFalse([string isEqualToString:nil], @"NSString isEqualToString");

    string = @"test";

    STAssertTrue([string isEqual:@"test"], @"NSString isEqual");
    STAssertTrue([string isEqualToString:@"test"], @"NSString isEqualToString");

    STAssertFalse([string isEqual:nil], @"NSString isEqual");
    STAssertFalse([string isEqualToString:nil], @"NSString isEqualToString");
}

Bardzo to polecam . Korzyści z wydajności wynikające z isEqualToString są w zasadzie pomijalne dla większości aplikacji. Ale są jeszcze dwie inne rozróżnienia, o których wspomina autor:

• Bezpieczeństwo typów
• Sposób niljest obsługiwany