En Objective-C, quel est l'équivalent du mot-clé «instanceof» de Java?


186

Je voudrais vérifier si un objet (par exemple someObject) est assignable (castable) à une variable d'un autre type (par exemple SpecifiedType). En Java, je peux écrire:

someObject instanceof SpecifiedType

Une question connexe est de savoir si le type d'exécution d'un objet est égal à un autre type. En Java, je peux écrire:

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

Comment cela peut-il être fait en Objective-C?


Réponses:


264

Essayez [myObject class]de renvoyer la classe d'un objet.

Vous pouvez faire des comparaisons exactes avec:

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

mais pas en utilisant directement l' MyClassidentifiant.

De même, vous pouvez trouver si l'objet appartient à une sous-classe de votre classe avec:

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

comme suggéré par Jon Skeet et zoul.


Comment vérifier l'égalité avec un objet de type "AnObject" par exemple?
Dimitris le

"if ([myObject class] == [AnObject class])" ou, comme suggéré par Jon Skeet et zoul: "if ([myObject isKindOfClass: [AnObject class]])"
mouviciel

8
une comparaison exacte peut également être effectuée avecif ([myObject isMemberOfClass:[MyClass class]])
user102008

37

De Wikipedia :

En Objective-C, par exemple, le générique Objectet NSObject(dans Cocoa / OpenStep) fournissent la méthode isMemberOfClass:qui renvoie truesi l'argument de la méthode est une instance de la classe spécifiée. La méthode isKindOfClass:retourne de manière analogue true si l'argument hérite de la classe spécifiée.

isKindOfClass:serait le plus proche instanceof, par les sons de celui-ci.


9

Consultez la méthode isKindOfClass: dans la documentation NSObject . (Le mot d'avertissement habituel pour une telle question est que la vérification de la classe d'objets est souvent le signe d'une erreur.)


2
Copiez simplement la "réponse" ci-dessous: "@Zoul - pourquoi l'utilisation de la vérification de type de classe est-elle considérée comme mauvaise? N'est-ce pas une bonne programmation défensive ou est-ce que vous soutenez que cela devrait être inutile?"
Dan Rosenstark

1
Aha, merci. Un problème est que les objets ne doivent pas nécessairement être de la classe que vous attendez. Pendant les tests, il est assez courant de passer un stub de classe qui honore l'interface, mais qui a une classe différente. Ou lorsque vous observez des changements de valeur à l'aide de KVO, une certaine magie est faite avec les classes. Les deux cas sont tout à fait légitimes et les deux sont facilement cassés si votre code effectue des vérifications de classe explicites. Le comportement de commutation sur la classe est une mauvaise conception OO, étroitement couplé et difficile à étendre. Je ne dis pas qu'il n'y a pas de cas d'utilisation légitime pour les contrôles de classe, mais vous devriez réfléchir à deux fois avant de le faire.
zoul

@zoul Dans ce cas précis, ce serait simplement de l'inexpérience, on utiliserait plus probablement + (BOOL)conformsToProtocol:(Protocol *)aProtocol.
EricLeaf
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.