J'ai une méthode de base virtuelle La première étape d'action consiste à appeler Je veux savoir s'il existe un mot-clé ou un modèle de conception qui me permettra de quitter la méthode dérivée de la méthode de base.
Actuellement, je cherche changer le vide à Bool et en l'utilisant comme un contrôle de flux, mais je me demandais s'il y a des autres modèles de conception, je pourrais pouvoir utiliser. action vide () qui est remplacé dans une classe dérivée.
base.action () . Si une situation se produit dans la méthode de base, je ne veux pas que le reste de la méthode dérivée soit traité.
3 Réponses :
est-ce une erreur "situation"? Si tel est le cas, faites-la jeter une exception et n'atteignez pas l'exception dans la substitution.
Si ce n'est pas une situation d'erreur, l'utilisation du type de retour sonne comme une voie à suivre, mais elle ne convient peut-être pas Votre contexte - nous ne savons pas vraiment ce que vous essayez d'atteindre.
Une autre option consiste à utiliser modèle de méthode de modèle : Si vous ne voulez pas faire le résumé de la classe de base, vous pouvez Faites-en une méthode virtuelle protégée qui ne fait rien dans la classe de base et est remplacé par la classe dérivée, le cas échéant. Notez que Si aucune de ces options ne semble appropriée, vous devez nous fournir des informations plus concrètes sur ce que vous avez 'RE essayant d'atteindre. Dosomething est pas virtuel ici.
lancer une exception dans la méthode de base. Il sortira de chaque méthode qui l'appelait jusqu'à ce qu'il soit capturé.
Jeter une exception dans une méthode appelée fréquemment n'est pas une très bonne idée.
@Mert: C'est une bonne idée dans la situation exceptionnelle , mais c'est une mauvaise idée de flux de contrôle dans la plupart des cas .
@Mert: Lancer des exceptions fréquemment n'est pas bonne, mais l'exception n'est que jetée lorsqu'il y a une "situation", comme l'a dit l'OP. Cela n'arrive pas à chaque fois que la méthode est appelée, car le débit normal doit exécuter le reste du code dans la méthode dérivée.
@Guffa: "Situation" n'est pas une erreur dans ce cas. "À l'heure actuelle, je cherche à changer le vide pour bool et à utiliser cela comme contrôle de flux" Il cherche un moyen d'utiliser cela dans le contrôle de flux, et les conditions de contrôle de flux se produisent très souvent sinon chaque fois.
@Mert: C'est votre interprétation. Juste parce que l'OP utilise le terme "contrôle de flux" pour la manipulation de ce que le code devrait faire dans différentes situations, cela ne signifie pas que cela ne peut pas être une erreur.
@Guffa: C'est mon interprétation? Comment vous interprenez-vous "non ce n'est pas une situation d'erreur alors que des exceptions ne fonctionneront pas - talib"? Fin de la conversation.
ne l'utilisez pas avec ou, s'il s'agit d'un exceptionnel situation, soulever une exception, comme les autres suggèrent. VOID type retourné, mais peut faire, disons bool
Ceci est un peu désordonné car il expose une mise en œuvre inutile à un consommateur de la classe.
@Slugart: Quelle mise en œuvre dont vous parlez?
Désolé signifiait que les détails de la mise en œuvre - action expose désormais le fait qu'il renvoie BOOL. Qu'est-ce que cela signifie pour le consommateur de la classe dérivée?
Qu'est-ce que cela signifie en fait , peut être spécifié dans la documentation / commentaires à la fonction. S'il s'agit d'une bonne ou d'une bonne conception, dépend de l'architecture / design du programme concret. Je n'ai aucune idée de ce que Contexte Whend soit ce code utilisé, alors offrez simplement une solution possite.
S'il s'agit d'une bonne ou d'une bonne conception dépend également de la question de savoir s'il respecte les principes de la conception orientée objet, l'une de ces encapsulations. J'essayais simplement de souligner que ce design fuit un détail de mise en œuvre.
Je pense que semble être la solution la plus simple, sans trop compléter le système. Je vais juste avoir besoin de le documenter correctement. Sur une note latérale, notre note de curiosité peut-elle que la méthode dérivée ait toujours le type de retour en tant que vide, car la valeur renvoyée ne sera jamais utilisée.
@Talib: Non, la méthode dérivée ne peut pas modifier le type de retour de la méthode qu'il dépasse. Pour être honnête, si c'est un détail de mise en œuvre, j'essaierais d'éviter de la mettre dans l'API publique.
Non, ce n'est pas une situation d'erreur alors que des exceptions ne fonctionneront pas.
Désolé gain (supprimé le message précédent sur n'avoir pas besoin d'une solution), j'ai toujours besoin d'une solution, le système devient assez complexe. Fondamentalement, il y a une variable de crédits_SPEDIABLE ailleurs dans le code. J'aimerais pouvoir désactiver toutes les actions de la classe de base s'il n'y a pas de crédits disponibles. J'aimerais pouvoir faire cela sans la classe dérivée ayant à dupliquer le code.