В Objective-C, что эквивалентно ключевому слову «instanceof» в Java?

185

Я хотел бы проверить, является ли объект (например someObject) назначаемым (приведенным) к переменной другого типа (например SpecifiedType). На Java я могу написать:

someObject instanceof SpecifiedType

С этим связан вопрос о том, равен ли тип времени выполнения объекта другому типу. На Java я могу написать:

someObject.getClass().equals(SpecifiedType.class)

Как это можно сделать в Objective-C?

objective-c types casting equality downcast Дартениус
источник
См. Также: stackoverflow.com/q/8294076/165674
Dheeraj Vepakomma

Ответы:

264

Попробуйте [myObject class]вернуть класс объекта.

Вы можете сделать точные сравнения с:

if ([myObject class] == [MyClass class])

но не с помощью прямого MyClassидентификатора.

Точно так же вы можете узнать, принадлежит ли объект подклассу вашего класса с помощью: 

if ([myObject isKindOfClass:[AnObject class]])

как предложено Джоном Скитом и Зулом.

оборота мувичиэль
источник
Как я могу проверить на равенство с объектом типа "AnObject", например?
Димитрис
«if ([myObject class] == [AnObject class])» или, как предложено Джоном Скитом и zoul: «if ([myObject isKindOfClass: [AnObject class]])»
mouviciel
8
Точное сравнение также может быть сделано сif ([myObject isMemberOfClass:[MyClass class]])
user102008
37

Из Википедии :

Например, в Objective-C и универсальный, Objectи NSObject(в Cocoa / OpenStep) предоставляют метод, isMemberOfClass:который возвращает, trueесли аргумент метода является экземпляром указанного класса. Метод isKindOfClass:аналогично возвращает true, если аргумент наследуется от указанного класса.

isKindOfClass:было бы ближе всего instanceof, по звукам этого.

Джон Скит
источник
9

См isKindOfClass: метод в NSObject документации. (Обычное предупреждающее слово для такого вопроса состоит в том, что проверка класса объекта часто является признаком неправильной работы.)

Zoul
источник
2
Просто скопируйте из «ответа» ниже: «@Zoul - почему использование проверки типов классов считается плохим? Это не хорошее защитное программирование, или вы утверждаете, что оно должно быть ненужным?»
Дэн Розенстарк
1
Ага, спасибо Одна проблема заключается в том, что объекты не обязательно должны быть того класса, который вы ожидаете. Во время тестирования довольно часто передают заглушку класса, которая поддерживает интерфейс, но имеет другой класс. Или когда вы наблюдаете изменения значений с помощью KVO, с классами происходит определенная магия. Оба случая вполне законны, и оба легко ломаются, если ваш код выполняет явные проверки классов. Поведение при переключении в классе - плохая конструкция ОО, тесно связанная и трудно расширяемая. Я не говорю, что нет законного варианта использования для проверок классов, но вы должны дважды подумать, прежде чем делать это.
zoul
@zoul В этом конкретном случае это была бы просто неопытность, которую можно было бы использовать с большей вероятностью + (BOOL)conformsToProtocol:(Protocol *)aProtocol.
EricLeaf