Как избежать удручения?

Мой вопрос касается особого случая суперкласса Animal.

1. Моя Animalможет moveForward()и eat().
2. Sealрасширяется Animal.
3. Dogрасширяется Animal.
4. И есть специальное существо, которое также расширяется, Animalназывается Human.
5. Humanреализует также метод speak()(не реализован Animal).

В реализации абстрактного метода, который принимает, Animalя хотел бы использовать speak()метод. Это кажется невозможным без ударов. Джереми Миллер написал в своей статье, что пахнет удрученным.

Каково было бы решение избежать уныния в этой ситуации?

Если у вас есть метод, который должен знать, имеет ли конкретный класс тип Human, чтобы что-то сделать, то вы нарушаете некоторые принципы SOLID , в частности:

• Принцип открытого / закрытого - если в будущем вам нужно добавить новый тип животного, который может говорить (например, попугай), или сделать что-то определенное для этого типа, ваш существующий код должен будет измениться
• Принцип сегрегации интерфейса - похоже, вы слишком много обобщаете. Животное может охватывать широкий спектр видов.

По моему мнению, если ваш метод ожидает определенного типа класса, чтобы вызвать его конкретный метод, измените этот метод так, чтобы он принимал только этот класс, а не его интерфейс.

Что-то вроде этого :

public void MakeItSpeak( Human obj );

и не так

public void SpeakIfHuman( Animal obj );

Проблема не в том, что вы унижены, а в том, что вы унижаетесь Human. Вместо этого создайте интерфейс:

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

Таким образом, условие не в том, что животное есть, а Humanв том, что оно может говорить. Это означает, что они mysteriousMethodмогут работать с другими, не относящимися к человеку подклассами до Animalтех пор, пока они реализуются CanSpeak.

Вы можете добавить Общение с животными. Собака лает, Человек говорит, Печать ... э-э-э ... Я не знаю, что делает печать.

Но, похоже, ваш метод предназначен для if (Animal is Human) Speak ();

Вопрос, который вы, возможно, захотите задать, - какая альтернатива? Трудно дать предложение, так как я не знаю точно, чего вы хотите достичь. Существуют теоретические ситуации, в которых даункастинг / апкастинг является лучшим подходом.

В этом случае реализация по умолчанию speak()в AbstractAnimalклассе будет:

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

В этот момент у вас есть реализация по умолчанию в классе Abstract - и она ведет себя правильно.

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

Да, это означает, что у вас есть попытки поймать разбросанные по коду для обработки каждого speak, но альтернативой этому является if(thingy is Human)вместо этого упаковка всех спиц.

Преимущество исключения состоит в том, что если в какой-то момент у вас есть что-то, что говорит (попугай), вам не нужно переопределять все свои тесты.

Даункинг иногда необходим и уместен. В частности, это часто уместно в тех случаях, когда у кого-то есть объекты, которые могут иметь или не иметь какую-то способность, и кто-то хочет использовать эту способность, когда она существует, при обработке объектов без этой способности каким-либо способом по умолчанию. В качестве простого примера, предположим, что a Stringспрашивают, равен ли он некоторому другому произвольному объекту. Чтобы одно Stringсовпадало с другим String, оно должно проверять длину и массив вспомогательных символов другой строки. Если a Stringспрашивают, равно ли оно a Dog, он не может получить доступ к длине Dog, но он не должен этого делать; вместо этого, если объект, с которым Stringдолжен сравнивать a, не являетсяStringсравнение должно использовать поведение по умолчанию (сообщая, что другой объект не равен).

Время, когда удушение следует считать наиболее сомнительным, это когда «известный» объект, о котором известно, что он имеет надлежащий тип. В общем, если известно, что объект является a Cat, следует использовать переменную типа Cat, а не переменную типа Animal, чтобы ссылаться на него. Однако бывают случаи, когда это не всегда работает. Например, Zooколлекция может содержать пары объектов в четных / нечетных слотах массива, ожидая, что объекты в каждой паре смогут воздействовать друг на друга, даже если они не могут воздействовать на объекты в других парах. В таком случае объекты в каждой паре все равно должны будут принимать неспецифический тип параметра, чтобы они могли синтаксически передавать объекты из любой другой пары. Таким образом, даже если CatэтоplayWith(Animal other)Метод будет работать только в том случае, если он otherбыл Cat, а Zooдолжен иметь возможность передавать ему элемент Animal[], поэтому его тип параметра должен быть, Animalа не Cat.

В тех случаях, когда снижение рейтинга на законных основаниях неизбежно, его следует использовать без каких-либо сомнений. Ключевой вопрос состоит в том, чтобы определить, когда можно разумно избегать удушения, и избегать его, когда это разумно возможно.

В реализации абстрактного метода, который принимает Animals, я хотел бы использовать метод speak ().

У вас есть несколько вариантов:

• Используйте отражение, чтобы позвонить, speakесли он существует. Преимущество: нет зависимости от Human. Недостаток: теперь есть скрытая зависимость от имени «говорить».

• Ввести новый интерфейс Speakerи снизить интерфейс. Это более гибко, чем в зависимости от конкретного типа бетона. Недостатком является то, что вы должны изменить его Humanдля реализации Speaker. Это не сработает, если вы не можете изменитьHuman

• Унизить до Human. Это имеет тот недостаток, что вам придется изменять код всякий раз, когда вы хотите, чтобы другой подкласс говорил. В идеале вы хотите расширить приложения, добавляя код, не возвращаясь и не меняя старый код.