Le remplacement d'une méthode peut-il être empêché par un downcasting vers une superclasse ?

Question

J'essaie de comprendre si la réponse à la question suivante est la même dans toutes les principales langues POO ;et sinon, en quoi ces langues diffèrent-elles ?

Supposons que j'ai cours A qui définit les méthodes act et jump;méthode act méthode d'appel jump. Ala sous-classe de B méthode de remplacement jump (c'est-à-dire que la syntaxe appropriée est utilisée pour garantir que chaque fois que jump est appelé, l'implémentation en classe B est utilisé).

j'ai un objet b de classe B.Je veux qu'il se comporte exactement comme s'il était de classe A.En d'autres termes, je veux que jump à effectuer en utilisant l'implémentation dans A.Quelles sont mes options dans les différentes langues ?

Par exemple, puis-je y parvenir avec une certaine forme de downcasting ?Ou peut-être en créant un objet proxy qui sait quelles méthodes appeler ?

Je voudrais éviter de créer un tout nouvel objet de classe A et en mettant soigneusement en place le partage de l'état interne entre a et b parce que ce n'est évidemment pas à l'épreuve du temps et compliqué.Je voudrais également éviter de copier l'état de b en un tout nouvel objet de classe A car il peut y avoir beaucoup de données à copier.

MISE À JOUR

J'ai posé cette question spécifiquement sur Python, mais il semble que cela soit impossible à réaliser en Python et techniquement, cela peut être fait...en quelque sorte..

Il semble qu'au-delà de la faisabilité technique, il existe de solides arguments contre cette démarche du point de vue de la conception.Je pose des questions à ce sujet dans une question distincte.

Answer 1

Les commentaires réitéraient :Préférez la composition à l’héritage.

L'héritage fonctionne bien lorsque vos sous-classes présentent des différences comportementales bien définies par rapport à leur superclasse, mais vous atteindrez fréquemment un point où ce modèle devient gênant ou cesse d'avoir du sens.À ce stade, vous devez reconsidérer votre conception.

La composition est généralement la meilleure solution.Déléguer le comportement variable de votre objet à un ou plusieurs objets différents peut réduire ou éliminer votre besoin de sous-classement.

Dans votre cas, les différences de comportement entre la classe A et la classe B pourraient être encapsulées dans le modèle de stratégie.Vous pouvez alors modifier le comportement de la classe A (et de la classe B, si nécessaire) au niveau de l'instance, simplement en attribuant une nouvelle stratégie.

Le modèle Strategy peut nécessiter plus de code à court terme, mais il est propre et maintenable.Le tourbillonnement des méthodes, les patchs de singe et toutes ces choses intéressantes qui nous permettent de fouiller dans l'implémentation de notre langage spécifique sont amusants, mais le potentiel d'effets secondaires inattendus est élevé et le code a tendance à être difficile à maintenir.

Answer 2

Ce que vous demandez n'a aucun rapport/non pris en charge par la programmation POO.

Si vous sous-classez un objet A avec classe B et remplacer ses méthodes, lorsqu'une instance concrète de B est créée puis toutes les implémentations remplacées/nouvelles des méthodes de base lui sont associées (soit on parle de Java, soit de C++ avec des tables virtuelles etc).

Vous avez un objet instancié B.
Pourquoi vous attendriez-vous à pouvoir/devriez/devriez pouvoir appeler la méthode de la superclasse si vous avez remplacé cette méthode ?

Vous pouvez bien sûr l'appeler explicitement, par ex.en appelant super à l'intérieur de la méthode, mais vous ne pouvez pas le faire automatiquement, et le casting ne vous aidera pas non plus à le faire.

Je ne peux pas imaginer pourquoi vous voudriez faire ça.
Si vous devez utiliser la classe A puis utilise la classe A.
Si vous devez remplacer sa fonctionnalité, utilisez sa sous-classe B.

Answer 3

La plupart des langages de programmation ont du mal à prendre en charge la répartition dynamique des fonctions virtuelles (cas de l'appel de la méthode remplacée jump dans une sous-classe au lieu de l'implémentation de la classe parent) -- dans la mesure où il est difficile de le contourner ou de l'éviter.En général, la spécialisation/polymorphisme est une fonctionnalité souhaitable – sans doute un objectif de la POO en premier lieu.

Jetez un oeil à l'article Wikipédia sur Fonctions virtuelles, qui donne un aperçu utile de la prise en charge des fonctions virtuelles dans de nombreux langages de programmation.Cela vous donnera un point de départ lorsque vous envisagez un langage spécifique, ainsi que les compromis à peser lorsque vous étudiez un langage dans lequel le programmeur peut contrôler le comportement de la répartition (voir la section sur C++, par exemple).

Donc, librement, la réponse à votre question est: "Non, le comportement n'est pas le même dans tous les langages de programmation." De plus, il n'y a pas de solution indépendante du langage.C++ peut être votre meilleur choix si vous besoin le comportement.

Answer 4

Vous pouvez réellement le faire avec Python (en quelque sorte), avec quelques horribles hacks.Cela nécessite que vous implémentiez quelque chose comme les wrappers dont nous parlions dans votre première question spécifique à Python, mais en tant que sous-classe de B.Vous devez ensuite également implémenter le proxy d'écriture (l'objet wrapper ne doit contenir aucun état normalement associé à la hiérarchie de classes, il doit rediriger tous les accès aux attributs vers l'instance sous-jacente de B.

Mais plutôt que de rediriger la recherche de méthode vers A, puis d'appeler la méthode avec l'instance encapsulée, vous appelleriez la méthode en passant l'objet wrapper comme self.C'est légal car la classe wrapper est une sous-classe de B, donc l'instance wrapper est une instance des classes dont vous appelez les méthodes.

Ce serait un code très étrange, vous obligeant à générer dynamiquement des classes en utilisant simultanément les relations IS-A et HAS-A.Cela finirait probablement aussi par être assez fragile et donnerait des résultats bizarres dans de nombreux cas particuliers (vous ne pouvez généralement pas écrire des classes wrapper 100% parfaites en Python exactement parce que ce genre de chose étrange est possible).

Je laisse complètement de côté la météo, que ce soit une bonne idée ou non.