Jak uniknąć downcastingu?

Moje pytanie dotyczy specjalnego przypadku superklasy Animal.

1. Moja Animalpuszka moveForward()i eat().
2. Sealrozszerza się Animal.
3. Dogrozszerza się Animal.
4. I jest specjalne stworzenie, które rozszerza także Animaltzw Human.
5. Humanimplementuje również metodę speak()(nie zaimplementowaną przez Animal).

W implementacji metody abstrakcyjnej, która akceptuje Animal, chciałbym użyć tej speak()metody. To nie wydaje się możliwe bez zrujnowania. Jeremy Miller napisał w swoim artykule, że pachnie przygnębiony.

Jakie byłoby rozwiązanie, aby uniknąć downcastingu w tej sytuacji?

Jeśli masz metodę, która musi wiedzieć, czy konkretna klasa jest typu Human, aby coś zrobić, to łamiesz niektóre zasady SOLID , w szczególności:

• Zasada otwarta / zamknięta - jeśli w przyszłości musisz dodać nowy typ zwierzęcia, który może mówić (na przykład papuga), lub zrobić coś specyficznego dla tego typu, Twój istniejący kod będzie musiał się zmienić
• Zasada segregacji interfejsu - wygląda na to, że generalizujesz za dużo. Zwierzę może obejmować szerokie spektrum gatunków.

Moim zdaniem, jeśli twoja metoda oczekuje określonego typu klasy, aby wywołać tę metodę, zmień tę metodę, aby akceptowała tylko tę klasę, a nie interfejs.

Coś takiego :

public void MakeItSpeak( Human obj );

i nie tak:

public void SpeakIfHuman( Animal obj );

Problemem nie jest to, że jesteś downcastingiem - to, że jesteś downcastingiem Human. Zamiast tego utwórz interfejs:

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
    }
    //....
}

W ten sposób warunkiem nie jest to, że zwierzę jest Human- warunkiem jest to, że może mówić. Oznacza to, że mysteriousMethodmogą współpracować z innymi niekluczowymi podklasami, o Animalile tylko się zaimplementują CanSpeak.

Możesz dodać Communicate to Animal. Pies szczeka, Człowiek mówi, Pieczęć ... Uch ... Nie wiem, co robi pieczęć.

Ale wygląda na to, że twoja metoda została zaprojektowana, jeśli (Animal is Human) Speak ();

Pytanie, które możesz zadać, brzmi: jaka jest alternatywa? Trudno podać sugestię, ponieważ nie wiem dokładnie, co chcesz osiągnąć. Istnieją teoretyczne sytuacje, w których downcasting / upcasting jest najlepszym podejściem.

W takim przypadku domyślną implementacją speak()w AbstractAnimalklasie będzie:

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

W tym momencie masz domyślną implementację w klasie Abstract - i działa ona poprawnie.

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

Tak, oznacza to, że masz rozrzuty rozrzucone po kodzie, aby obsłużyć każdy speak, ale alternatywą jest if(thingy is Human)owijanie wszystkich wypowiedzi.

Zaletą tego wyjątku jest to, że jeśli masz coś innego, co mówi (papuga), nie będziesz musiał zaimplementować wszystkich swoich testów.

Downcasting jest czasem konieczny i odpowiedni. W szczególności jest to często odpowiednie w przypadkach, w których ktoś posiada przedmioty, które mogą, ale nie muszą, mieć jakąś zdolność, i chce skorzystać z tej zdolności, gdy istnieje, podczas obsługi obiektów bez tej zdolności w pewien domyślny sposób. Jako prosty przykład, załóżmy, że a Stringjest pytane, czy jest ono równe jakimś innemu dowolnemu obiektowi. Aby jeden Stringbył równy String, musi zbadać długość i tylną tablicę znaków drugiego łańcucha. Jeśli a Stringzostanie zapytane, czy jest równe a Dog, nie może uzyskać dostępu do długości Dog, ale nie powinno tak być; zamiast tego, jeśli obiekt, do którego Stringma się porównać a, nie jestString, porównanie powinno wykorzystywać zachowanie domyślne (zgłaszanie, że drugi obiekt nie jest równy).

Moment, w którym spuszczanie wody należy uznać za najbardziej wątpliwe, to moment, w którym rzucany przedmiot jest „znany” z właściwego rodzaju. Ogólnie rzecz biorąc, jeśli obiekt jest znany jako Cat, należy do niego użyć zmiennej typu Cat, a nie zmiennej typu Animal. Są jednak chwile, kiedy to nie zawsze działa. Na przykład Zookolekcja może przechowywać pary obiektów w parzystych / nieparzystych gniazdach tablicowych, oczekując, że obiekty w każdej parze będą mogły na siebie oddziaływać, nawet jeśli nie będą mogły oddziaływać na obiekty w innych parach. W takim przypadku obiekty w każdej parze nadal będą musiały zaakceptować nieokreślony typ parametru, tak że mogłyby składniowo przekazać obiekty z dowolnej innej pary. Tak więc, nawet jeśli Cat„splayWith(Animal other)metoda działałaby tylko wtedy, gdy otherbyła a Cat, Zoomusiałaby móc przekazać jej element an Animal[], więc typem parametru musiałaby być Animalzamiast Cat.

W przypadkach, gdy downcasting jest prawnie nieunikniony, należy go używać bez żadnych skrupułów. Kluczowym pytaniem jest ustalenie, kiedy można rozsądnie uniknąć upuszczenia i unikanie go, gdy jest to rozsądnie możliwe.

W realizacji abstrakcyjnej metody, która akceptuje Zwierzęta, chciałbym użyć metody speak ().

Masz kilka możliwości:

• Użyj odbicia, aby zadzwonić, speakjeśli istnieje. Zaleta: brak zależności od Human. Wada: teraz istnieje ukryta zależność od nazwy „mówić”.

• Wprowadź nowy interfejs Speakeri spuść do interfejsu. Jest to bardziej elastyczne niż w zależności od konkretnego rodzaju betonu. Ma tę wadę, że trzeba ją zmodyfikować, Humanaby zaimplementować Speaker. To nie zadziała, jeśli nie możesz modyfikowaćHuman

• Downcast to Human. Ma to tę wadę, że będziesz musiał zmodyfikować kod, ilekroć chcesz mówić innej podklasie. Idealnie chcesz rozszerzyć aplikacje, dodając kod bez ciągłego cofania się i zmieniania starego kodu.