Comment éviter le downcasting?

Ma question concerne un cas particulier de la super classe Animal.

1. Ma Animalboîte moveForward()et eat().
2. Seals'étend Animal.
3. Dogs'étend Animal.
4. Et il y a une créature spéciale qui s'étend également Animalappelée Human.
5. Humanimplémente également une méthode speak()(non implémentée par Animal).

Dans une implémentation d'une méthode abstraite qui accepte, Animalje voudrais utiliser la speak()méthode. Cela ne semble pas possible sans faire un abattage. Jeremy Miller a écrit dans son article qu'une odeur baissée sent.

Quelle serait une solution pour éviter la rétrogradation dans cette situation?

Si vous avez une méthode qui doit savoir si la classe spécifique est de type Humanafin de faire quelque chose, alors vous brisez certains principes SOLIDES , en particulier:

• Principe ouvert / fermé - si, à l'avenir, vous devez ajouter un nouveau type d'animal qui peut parler (par exemple, un perroquet), ou faire quelque chose de spécifique pour ce type, votre code existant devra changer
• Principe de ségrégation des interfaces - il semble que vous généralisiez trop. Un animal peut couvrir un large éventail d'espèces.

À mon avis, si votre méthode attend un type de classe particulier, pour appeler sa méthode particulière, changez cette méthode pour n'accepter que cette classe, et non son interface.

Quelque chose comme ça :

public void MakeItSpeak( Human obj );

et pas comme ça:

public void SpeakIfHuman( Animal obj );

Le problème n'est pas que vous abaissez - c'est que vous abattez Human. À la place, créez une interface:

public interface CanSpeak{
    void speak();
}

public abstract class Animal{
    //....
}

public class Human extends Animal implements CanSpeak{
    public void speak(){
        //....
    }
}

public void mysteriousMethod(Animal animal){
    //....
    if(animal instanceof CanSpeak){
        ((CanSpeak)animal).speak();
    }else{
        //Throw exception or something
    }
    //....
}

De cette façon, la condition n'est pas que l'animal soit Human- la condition est qu'il puisse parler. Cela signifie qu'il mysteriousMethodpeut fonctionner avec d'autres sous-classes non humaines Animaltant qu'elles sont implémentées CanSpeak.

Vous pouvez ajouter Communiquer à l'animal. Le chien aboie, l'homme parle, le phoque ... euh ... Je ne sais pas ce que fait le phoque.

Mais il semble que votre méthode soit conçue pour (Animal est humain) parler ();

La question que vous voudrez peut-être poser est quelle est l'alternative? C'est difficile de donner une suggestion car je ne sais pas exactement ce que vous voulez réaliser. Il existe des situations théoriques où le downcasting / upcasting est la meilleure approche.

Dans ce cas, l'implémentation par défaut de speak()dans la AbstractAnimalclasse serait:

void speak() throws CantSpeakException {
  throw new CantSpeakException();
}

À ce stade, vous avez une implémentation par défaut dans la classe Abstract - et elle se comporte correctement.

try {
  thingy.speak();
} catch (CantSeakException e) {
  System.out.println("You can't talk to the " + thingy.name());
}

Oui, cela signifie que vous avez des tentatives de captures éparpillées dans le code pour gérer tout speak, mais l'alternative à cela consiste à if(thingy is Human)envelopper tous les discours à la place.

L'avantage de l'exception est que si vous avez un autre type de chose qui parle (un perroquet), vous n'aurez pas besoin de réimplémenter tous vos tests.

La descente est parfois nécessaire et appropriée. En particulier, cela est souvent approprié dans les cas où l'on a des objets qui peuvent ou non avoir une certaine capacité, et on souhaite utiliser cette capacité lorsqu'elle existe tout en manipulant des objets sans cette capacité d'une manière par défaut. À titre d'exemple simple, supposons que l' Stringon demande à a s'il est égal à un autre objet arbitraire. Pour que l'un soit Stringégal à un autre String, il doit examiner la longueur et le tableau de caractères de support de l'autre chaîne. Si Stringon demande à a s'il est égal à a Dog, cependant, il ne peut pas accéder à la longueur de Dog, mais il ne devrait pas avoir à le faire; au lieu de cela, si l'objet auquel a Stringest censé se comparer n'est pas unString, la comparaison doit utiliser un comportement par défaut (signalant que l'autre objet n'est pas égal).

Le moment où la descente doit être considéré comme le plus douteux est celui où l'objet projeté est "connu" pour être du type approprié. En général, si un objet est connu pour être un Cat, il faut utiliser une variable de type Cat, plutôt qu'une variable de type Animal, pour s'y référer. Il y a des moments où cela ne fonctionne pas toujours, cependant. Par exemple, une Zoocollection peut contenir des paires d'objets dans des emplacements de tableau pairs / impairs, en s'attendant à ce que les objets de chaque paire puissent agir les uns sur les autres, même s'ils ne peuvent pas agir sur les objets des autres paires. Dans un tel cas, les objets de chaque paire devraient toujours accepter un type de paramètre non spécifique de sorte qu'ils pourraient, syntaxiquement , transmettre les objets de toute autre paire. Ainsi, même si Catl »playWith(Animal other)La méthode ne fonctionnerait que lorsque otherétait un Cat, le Zoodevrait avoir la possibilité de lui passer un élément d'un Animal[], donc son type de paramètre devrait être Animalplutôt que Cat.

Dans les cas où la descente est légitimement inévitable, il faut l'utiliser sans scrupule. La question clé est de déterminer quand on peut sensiblement éviter la descente, et de l'éviter quand c'est raisonnablement possible.

Dans une implémentation d'une méthode abstraite qui accepte les animaux, je voudrais utiliser la méthode speak ().

Vous avez quelques choix:

• Utilisez la réflexion pour appeler speaksi elle existe. Avantage: pas de dépendance Human. Inconvénient: il existe désormais une dépendance cachée sur le nom "speak".

• Introduisez une nouvelle interface Speakeret abaissez l'interface. Ceci est plus flexible qu'en fonction d'un type de béton spécifique. Il présente l'inconvénient que vous devez modifier Humanpour l'implémenter Speaker. Cela ne fonctionnera pas si vous ne pouvez pas modifierHuman

• Descendu à Human. Cela présente l'inconvénient que vous devrez modifier le code chaque fois que vous voulez qu'une autre sous-classe parle. Idéalement, vous souhaitez étendre les applications en ajoutant du code sans revenir en arrière et modifier l'ancien code.