Як уникнути зриву?

Моє запитання стосується особливого випадку тварини суперкласу.

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.

Ви можете додати спілкування для тварин. Собака гавкає, Людина розмовляє, Тюлень .. е-е .. Я не знаю, що робить тюлень.

Але це здається, що ваш метод розроблений для того, щоб (Animal is Human) говорити ();

Питання, яке ви можете задати, полягає в тому, яка альтернатива? Важко дати пропозицію, оскільки я не знаю точно, чого ви хочете досягти. Існують теоретичні ситуації, коли кращий підйом / оновлення є найкращим підходом.

У цьому випадку реалізацією за замовчуванням speak()у AbstractAnimalкласі буде:

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

У цей момент у вас є реалізація за замовчуванням у класі Анотація - і вона веде себе правильно.

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

Так, це означає, що у вас є коди, розповсюджені по коду, щоб обробити кожного speak, але альтернативою цьому є if(thingy is Human)обговорення всіх виступів замість цього.

Перевага винятку полягає в тому, що якщо у вас є якийсь інший предмет, який говорить (папуга), вам не потрібно буде повторно виконувати всі ваші тести.

Спускання з місця іноді необхідне та доречне. Зокрема, це часто доцільно у тих випадках, коли в когось є об'єкти, які можуть мати, а можуть і не мати певну здатність, і хочеться використовувати цю здатність, коли вона існує під час обробки об'єктів без такої здатності якось за замовчуванням. Приклади просто, припустимо String, запитується, чи дорівнює він якомусь іншому довільному об'єкту. Для того, Stringщоб один дорівнював іншому String, він повинен вивчити масив довжини та резервного символу другого рядка. Якщо а Stringзапитують, чи дорівнює Dogвін, то він не може отримати доступ до довжини Dog, але це не повинно бути; натомість, якщо об'єкт, з яким Stringмає порівнювати себе, не єString, порівняння має використовувати поведінку за замовчуванням (повідомляючи, що інший об'єкт не є рівним).

Час, коли зрив каналу слід вважати найбільш сумнівним, це коли "відомий" об'єкт, який викидається, належного типу. Загалом, якщо об'єкт, як відомо, є a Cat, для його використання слід використовувати змінну типу Cat, а не змінну типу Animal. Однак бувають випадки, коли це не завжди працює. Наприклад, Zooколекція може містити пари об'єктів у слотах парного / непарного масиву, сподіваючись, що об'єкти кожної пари зможуть діяти один на одного, навіть якщо вони не зможуть діяти на об'єкти інших пар. У такому випадку об’єкти в кожній парі все одно повинні прийняти неспецифічний тип параметра, такий, що вони могли б синтаксично передавати об'єкти з будь-якої іншої пари. Таким чином, навіть якщо Cat'splayWith(Animal other)метод буде працювати лише тоді, коли otherбув a Cat, Zooпотрібно було б мати можливість передавати йому елемент an Animal[], тому його тип параметра повинен бути, Animalа не Cat.

У тих випадках, коли зрив мотивів законно неминучий, його слід використовувати без особливих труднощів. Ключове питання полягає у визначенні того, коли можна розумно уникнути занепаду, та уникнути цього, коли це можливо.

У реалізації абстрактного методу, який приймає тварин, я хотів би використовувати метод speak ().

У вас є кілька варіантів:

• Використовуйте відображення для дзвінка, speakякщо він існує. Перевага: відсутність залежності від Human. Недолік: зараз існує прихована залежність від назви "говорити".

• Введіть новий інтерфейс Speakerта скасувати його на інтерфейс. Це більш гнучко, ніж залежно від конкретного типу бетону. Він має той недолік, який вам доведеться модифікувати Humanдля реалізації Speaker. Це не спрацює, якщо ви не можете змінитиHuman

• Вниз до Human. Це має той недолік, що вам доведеться змінювати код, коли ви хочете говорити іншим підкласом. В ідеалі ви хочете розширити програми, додаючи код, не повторюючись і не змінюючи старий код.