Dans le deuxième chapitre de son livre de programmation IOS, Joe Conway décrit en utilisant des méthodes de classe en cas de sous-classement. Je comprends ce concept et j'ai une question sur la question du sous-classement.
Contexte: Nous avons créé une classe de possession dont la méthode de classe + Randompossession ressemble à ceci: p>
+(id)randomPossession
{
BallGlove *myGlove = [super randomPossession];
NSArray *brandNames = [NSArray arrayWithObjects:@"Rawlings", @"Mizuno", @"Wilson", nil];
unsigned long randomNameIndex = rand() % [brandNames count];
[myGlove setBrandName:[brandNames objectAtIndex:randomNameIndex]];
NSLog(@"myGlove is of type class: %@", [self class]);
return myGlove;
}
4 Réponses :
Oui, il est acceptable de faire votre initialisation comme ça. En fait, c'est comment cela se fait dans la plupart des cas. Je veux dire, c'est la raison de hériter d'une super classe en premier lieu. Vous voulez des choses en plus de ce qui est présent dans la super classe. Donc, vous insérez du code sur tout ce qui est spécifique à la classe héritée et cela devrait être fait de cette façon.
Je pense comment vous voulez que l'objet initialisé En outre, peu importe si vous retournez de type BallGlove est également un facteur de la manière dont vous définissez votre méthode héritée. La question se pose sur appeler le possession init ou appeler le ballglove init (non que la création d'une instance d'une classe est le seul endroit où utiliser une méthode de classe). Donc, il s'agit de la logique de la création de vos objets, c'est-à-dire comment vous décrivez-vous ballgozove vous assurez-vous que votre méthode de classe le décrit d'une manière qui correspond au ballgove Critères d'objet et ne deviennent pas génériques possession objet. Ma réponse est que si vous pouvez la mettre en œuvre correctement, l'utilisation d'une ligne parallèle de méthodes de classe est acceptable.
possession dans votre super classe car, id peut pointer sur un objet de n'importe quel type de classe
Merci pour la réponse. Cela n'a pas vraiment répondu à la question cependant. La question concerne le format des méthodes de classe dépassant. Outre la nécessité de générer une méthode de commodité pour une sous-classe, je ne suis pas sûr d'une raison de remplacer la méthode de la classe. Comme c'est tel, je n'ai rien vu à ce sujet. Existe-t-il des exemples vérifiant que le format que j'ai utilisé est approprié?
@Brianpalma je suis désolé. Peut-être que je n'ai pas répondu à droite. Je ne vois pas vraiment pourquoi il n'est pas acceptable de le faire pour les méthodes de classe de la même manière que les initialisateurs. La façon dont je trouve que cela fonctionne est, les méthodes de classe ont tendance à appeler des méthodes init, à effectuer un certain code et à renvoyer une version autoréélise qui est ce que vous faites. Je ne sais pas s'il y a des exemples de vérification de votre format, mais je ne vois pas non plus de problèmes qui pourraient en survenir. Permettez-moi de vérifier certains codes d'échantillonnage et de vous contacter.
Yep, c'est une façon parfaitement judicieuse de le faire. Il n'y a rien de particulièrement différent entre les méthodes de classe et les méthodes normales - juste que l'une est effectuée par une classe et l'autre est effectuée par une instance.
Le moment où vous remplacez une méthode de classe, vous pouvez décider de la mettre en œuvre à l'aide de la super mise en œuvre ou sans cela. C'est totalement à vous de décider. Overiding Init est une histoire complètement différente, non seulement parce que c'est une méthode d'instance, mais qu'il y a une convention / un contrat associé à celui-ci. Gardez à l'esprit que, par exemple, les méthodes, le principe de sous-contrôle Liskov ne doit pas être violé.
VOTRE OBLIÉDISÉE DE LA MÉTHODE DE LA CLASSE EST PARFAITE Bien, bien que je puisse envisager des méthodes de classe une odeur de conception. Bien que cela soit très possible dans l'objectif-c, ce n'est pas dans d'autres langues et que pour une très bonne raison. Le polymorphisme en tant que concept est mieux lié aux instances qui peuvent être utilisées comme substituts les uns des autres, alors que l'utilisation de méthodes de classe enfreint le concept (c'est-à-dire aucune subtitrulation réelle). C'est intelligent, mais pas nécessairement intuitif et flexible.
Merci pour la réponse. Comme je l'ai mentionné ci-dessous, je ne suis au courant d'aucune utilisation de la priorité à une méthode de classe particulière dans une sous-classe autre que pour moins de code dans une méthode de commodité. À ce stade, je n'ai aucune intention de le faire. J'étais simplement curieuse quant à la bonne mise en œuvre si la situation est apparue.
@Brianpalma: Il y a des raisons de remplacer les méthodes de classe autre que les «méthodes de commodité». Par exemple, Nsview's ParfaulyMenu et ConcedeSsSRINTTAINTBASEDLayout Les méthodes de classe existent juste pour être remplacées.
@CHUCK DÉSOLÉ, je pense que je me suis malfaisible ou que je suis trop nouveau! Je veux dire "méthodes de commodité" en termes d'objets de modèle. Je comprends qu'il existe des méthodes de classe dans iOS et OS X qui existent uniquement à être remplacées et nécessitent [Super SomeclassMethodhere];
@Brianpalma jetez un coup d'œil à cette réponse Stackoverflow.com/Questtions/5222083/...
@Madhavanrp à nouveau, cela ne répond pas à la question. Je crois que la question a été répondue de manière adéquate par Chuck. En fait, j'ai besoin de la mise en œuvre de la superclasse pour définir correctement les variables de ma sous-classe 'hérité de ivars. La question centrée sur une implémentation appropriée. Merci.
@Brianpalma: Comme indiqué dans ma réponse: "Au moment où vous remplissez une méthode de classe, vous pouvez décider de le mettre en œuvre avec l'aide de la superfilement ou sans cela. C'est totalement à vous.". Il n'y a pas de convention à suivre. Votre implémentation va bien.
C'est techniquement ok.
Je proposerais une alternative, cependant. Si vous avez déjà un initialiseur public désigné sur votre classe de base (que vous souhaiterez peut-être créer et appelez de cette méthode de classe d'usine), puis utilisez cet initialiseur (ou même un nouveau de votre sous-classe) dans la classe de votre sous-classes méthode.
Ce n'est pas beaucoup plus de code, mais à mon avis, plus facile à suivre et à la preuve future. L'initialisateur pourrait être aussi pratique à un moment donné, mais bien sûr, ce n'est pas une solution pour chaque application.
+ Randompossession dans la classe de base en fait appelle l'initialiseur désigné. La méthode de classe crée également des valeurs "aléatoires" pour cet initialisateur. Si je fais ce que je pense que vous vous suggérez, je devrais reproduire le code de ces valeurs "aléatoires" dans la méthode de classe remplie (+ Randompossession) et remplacer l'initialiseur désigné pour appeler un nouvel initialisateur de classifieur de classes de balle. Ajoutez mon ivar supplémentaire info. Pourquoi remplacer la méthode de la classe alors que j'ai proposé préjudiciable dans un sens général? Ne peut-il pas être comparé de chaînonner des initialiseurs?
Je ne pense pas que ce soit trop laid -il n'est tout simplement pas un modèle très courant. La question elle-même est un bon indicateur pour cela. :) Une chose qui devient un peu vague avec le sous-classement est le nom de la méthode et une bonne nommée est l'une des meilleures choses sur l'objectif-c. Donc, dans votre cas, une méthode + RandomballGlove pourrait être meilleure que de remplacer.
Vous suggérez que je crée plutôt une méthode de classe nommée + RandomballGlove comprenant la mise en œuvre de + Randompossession en plus de la mise en œuvre personnalisée souhaitée? Cela me semble bien. Que suggérez-vous de + Randomposssession toujours disponible pour les sous-classes de possession? Remplacez la méthode et faites-la jeter une exception en dirigeant l'utilisation de + RandomballGlove? Est-ce typiquement le protocole normal de tels événements? Je sais que cet exemple peut être inexistant en réalité, je suis juste en train d'apprendre et je suis curieux quant à la mise en œuvre acceptée en cas d'événement. Merci pour ton aide!
De plus, je sais que ce n'est peut-être pas un modèle très courant, mais la simple reconnaissance d'un tel événement par Big Nerd Ranch suggère qu'il existe une certaine validité à ma question. Ils ne sont pas tous, finalement tous, mais bien comprendre les détails de la mise en œuvre comme ceux-ci permettent une réflexion élargie dans le codage futur. J'apprécie vraiment l'aide!
C'est vraiment un sujet intéressant, et je ne pense pas qu'il ait été donné de nombreuses lignes directrices à cet égard au développeur. Lancer des exceptions se sent mal et artificielle pour moi. Obj-C soutient toujours des blocs de code amicaux qui se respectent et travaillent ensemble. Il ne va pas de longueurs pour interdire l'appel d'une méthode privée, par exemple.