comment appeller une méthode statique ?
yodark
Membre
Bonjour à tous,
Je voudrais savoir comment faire pour appeler les méthodes d'une classe static ? Sans avoir a instancier un objet
Par exemple en java je peux faire Math.random() ce qui appelle la fonction random de la classe Math sans que j'aie besoin de créer un nouvel objet Math
Je voudrais savoir comment faire pour appeler les méthodes d'une classe static ? Sans avoir a instancier un objet
Par exemple en java je peux faire Math.random() ce qui appelle la fonction random de la classe Math sans que j'aie besoin de créer un nouvel objet Math
Connectez-vous ou Inscrivez-vous pour répondre.
Réponses
[NomObject methodeStatique];
exemple avec + (NSView *)focusView :
NSView* view=[NSView focusView];
Le vocabulaire utilisé en Objective-C dans ce cas, c'est méthode de classe
Sauf qu'il faudrait plutôt écrire :
[NomDeClasse methodeStatique];
puisque c'est une méthode de classe comme l'a dit Philippe dans son message.
Petite question à ce même propos comment je fais pour creer une variable statique de classe ?
Je voudrais y accéder en faisant MaClasse.maVariable
J'ai pas vraiment trouvé compris comment on fait... La même chose que pour une variable normale ? Mais ca ne fonctionne pas
return variableDeClasse;
}
appel :
[MaClasse variableDeClasse];
Initialisation dans la méthode +(void) initialize
Mais bon, ce n'est pas très Objective-C-friendly ... Pose-toi la question de l'utilité de cette variable de classe.
On conseille plutôt de regrouper les variables globales dans un singleton.
Désoler mais je ne vois pas bien de quoi tu veux parler par singleton, tu aurais un exemple stp? Merci
Conceptuellement, je ne vais pas me mouillerÂ
En génie logiciel, le singleton est un patron de conception (design pattern) dont l'objet est de restreindre l'instanciation d'une classe à un seul objet (ou bien à quelques objets seulement). Il est utilisé lorsque l'on a besoin d'exactement un objet pour coordonner des opérations dans un système.
Par exemple [NSApplication sharedApplication] désigne l'unique instance de NSApplication dans le programme, [NSWorkspace sharedWorkspace] l'unique instance de NSWorkspace, [NSNotificationCenter defaultCenter] etc ...
Dans un programme, un singleton peut être une instance fournissant un certain nombre de services visibles/transformables de l'ensemble des instances.
Maintenant, par rapport à tes besoins, à toi de voir ...
Je ne connais pas ton projet, je dis seulement :
Elle peut être utile, comme elle ne peut-être que bidouillage ou programme mal structuré, et que si Obj-C permet les variables de classe mais ne l'as pas prévu, c'est que ce n'est pas l'esprit du langage.
Super lourd je dirais
Par exemple, on peut utiliser un singleton pour gérer les préférences d'une appli, c'est dans ce cas tout à fait justifié.
En plus avec les @property ça devient sympa à utiliser:
int valeur=[Preferences instance].valeur;
Mais une variable static de classe n'est pas une variable globale à l'appli mais à la classe, donc l'utilisation d'un singleton n'a pas de sens.
Je persiste à utiliser le terme static car c'est vraiment le cas, ça colle comme de la glue
Si un object B hérite de A et les deux implémentent la même méthode de classe, pour appeler cette méthode on fait:
[A methodeDeClasse];
[B methodeDeClasse];
Maintenant si on a une variable qui peut être A ou B, alors on doit faire:
[[maVar class] methodeDeClasse];
C'est vraiment collé à la classe, c'est pas dynamique quoi, à l'inverse du C++;
maVarCPP.methodeDeClasse(); // ça appelle la bonne méthode directement
Pour cette même raison, si on veut que B appelle la méthode de A, il faut faire:
Non ce n'est pas per-lourd si on a pris l'habitude d'avoir dans son template de projet un singleton destiné à ce genre de choses. A chaque création d'un nouveau projet le singleton est prêt, il ne reste plus qu'à le remplir au fur et à mesure des besoins.
Cela n'apparaà®t lourd que la première fois. Mais cela dépend ce qu'on fait de cette variable de classe, effectivement.
Le singleton existe déjà dans ce cas.
Tu es sur qu'il faille redéfinir la méthode pour simplement appeler l'implémentation de la classe parente ?
C'est juste une manière plus " Cocoa " de faire.
Non... Quand on sous-classe une vue, on ne redéfinit pas "setNeedsDisplay:" par exemple.
Dans ce cas où la méthode ne fait rien, c'est bien sûr inutile.
Mais on peut imaginer que B récupère la valeur d'une variable statique de A et effectue un traitement à partie de celle-ci.
Il est vrai que au lieu de :
[[self superclass] methodeDeClasse]; // appelle de A
on peut faire:
[A methodeDeClasse];
Ce qui ressemble curieusement au C++, en fait !
A::methodeDeClasse();
ou [B methodeDeClasse]
Donc c'est pas parce qu'Apple le fait que c'est bien et parfait, on sait tous que parfois dans leurs exemples y'a pas toujours des trucs hypercleans (mais au moins il y a des exemples
Maintenant, en Cocoa, il y a beaucoup de variables globales car ObjectiveC ne permet pas de faire autrement, par ex le nom des notifications pourraient être des variables statiques de la classe concernée (constantes de classes), mais le problème c'est qu'on peut pas y accéder directement comme en java ou C++:
NSWindow.NSWindowDidCloseNotification;
Pas possible en ObjC sans passer par une méthode (lourd !) d'où les variables globales.
Le mot static ne signifie pas la même chose selon les langages. En C, et donc enObj-C , static signifie selon K&R :
La déclaration static limite la portée de cet objet à la suite du fichier source en cours de compilation.
Je rajoute : et leur durée de vie est non limitée.
Il faut reconnaà®tre qu'après cela en faire des variables vues de tous, c'est possible, mais c'est bizarre.
Là on a une constante. Si on veut limiter la portée d'une constante à une unité de compilation, on mettra static éventuellement devant.
Si c'est possible : dans le fichier déclarateur on met
    NSString * const MACHIN=@truc;
sans static pour qu'il puisse être vu, et dans le fichier utilisateur
    extern NSString * const MACHIN;
A noter que si on met static NSString * const MACHIN=@truc; la déclaration extern amène une erreur au linkage.
En même temps, SQLite est multi-langage, alors tout refaire pour Obj-C, et risquer des comportements différents ...
C'est bien là le problème.
C'est donc une variable globale.
Idem que précédemment.
Je vais nuancer tes dires, Philippe :
si techniquement parlant, static créé l'emplacement de la variable dans l'application heap (comme par ailleurs toute variable déclarée en dehors de toute fonction),
déclarer une variable en static à l'intérieur d'une fonction est un non-sens :
en effet, sa visibilité sera uniquement que dans la fonction, et la décla en static interdira de la réutiliser même en utilisant extern dans le même fichier source (mais dans une autre fonction par exemple).
Sauf si on a besoin de la variable que dans la fonction, on utilise alors une variable statique pour sa qualité de durée de vie.
Par exemple si on a besoin d'une fonction factorielle, on stocke dans un tableau les factoriels déjà calculées et cela gagne du temps.
Quel problème ? c'est la règle du jeu du mot static en C. Ce n'est pas un problème, il suffit de ne pas mettre static, si on ne veux pas qu'une variable/fonction soit réservée à l'unité de compilation.
Non, c'est une variable accessible sur demande explicite, comme tout en C : On fait #include et on peut utiliser le matériel !
Mais que pourrait-on vouloir d'autre ?
Au programmeur de choisir une option entre
des déclarations extern
l'import d'un fichier de constantes
l'import d'un fichier de variables gérées par un singleton
le modèle des méthodes de classes décrit plus haut.
selon ses besoins.
Quand au titre du post, il montre bien l'ambiguité du mot statique selon les langages. En C, une méthode statique ne sera pas disponible justement si elle est précédée de static
Ceci fonctionne
NSString * standardMACHIN(void) ; dans ClassA
extern NSString * standardMACHIN(void) ; dans ClassB
Ceci ne fonctionne pas
static NSString * standardMACHIN(void) ; dans ClassA
extern NSString * standardMACHIN(void) ; dans ClassB
À vrai dire, je le trouve particulièrement crade
Utiliser "nil" à la place de "NULL" déjà :P
Ensuite, la préparation de la requête, c'est peanuts face à l'exécution... si c'est pour gagner 3 ms sur 5 s...
... qui sont généralement cachées par des singletons :P
Ce n'est pas sans aucune raison, le fait est que les variables statiques sont initialisées avant même l'entrée dans la fonction main. ça a peu de conséquences en C ou en Objective-C, mais en C++ avec des instances statiques ça peut donner des trucs terribles !
Le fait est aussi que ça sort de la conception POO.
C'est bien un problème pour un langage dit orienté objet non ?
C'est valable pour tout y compris les classes ...
Mais on tourne en rond, je dis qu'en ObjC il n'y a pas de vrai variable de classe et toi tu me dis qu'il suffit de les mettre externes, ce qui n'est pas très POO (comme dit schlum), en java pas possible de faire ce genre de bidouille infâme.
Globalement, ObjC a de nombreuses lacunes:
- pas de vrai variable de classe
- pas de classe abstraite
- pas de méthode abstraite
- pas d'espace de nommage (bien regrettable !)
Ce qui n'enlève rien aux qualités de Cocoa.