Наследование указанных методов в Java - PullRequest
0 голосов
/ 06 января 2019

Возможно ли в Java наследовать некоторые методы из базового класса, но не все из них? Просто чтобы прояснить, я покажу вам, что я имею в виду: Предположим, у нас есть базовый класс Visitor

public abstract class Visitor {}

Из Visitor мы создаем еще 2 объекта, клиента и компаньона:

public class Client extends Visitor {}
public class Companion extends Visitor {}

В клиенте мы создаем метод:

boolean has_Companion() {}

Чтобы достичь полиморфизма во время выполнения, нам нужно также объявить метод в Visitor:

abstract boolean has_Companion();

Проблема в том, что, поскольку мы объявляем метод в Visitor, Companion также наследует его. Мы этого не хотим. При компиляции я получаю следующую ошибку:

Тип Companion должен реализовывать унаследованный абстрактный метод Visitor.has_Companion ()

Нет смысла в реализации метода has_Companion () для Companion, потому что он никогда не будет использоваться. Это пустая трата кода. Могу ли я избежать этого каким-либо образом? Может ли метод has_Companion () быть унаследован только клиентом, а не Companion?

1 Ответ

0 голосов
/ 06 января 2019

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

Идея 1 : иметь Companion переопределить hasCompanion и просто всегда возвращать false.

Идея 2 : Пусть Visitor обеспечивает реализацию hasCompanion, которая просто всегда возвращает false. Затем Клиент переопределит hasCompanion с помощью действующей логики, чтобы определить, есть ли у Клиента спутник.

Идея 3 : не назначайте hasCompanion метод Visitor, а используйте метод только в Client. Затем код выполняет проверку типа во время выполнения с помощью оператора instanceof и вызывает метод на Client посредством приведения. Пример:

if (visitor instanceof Client) {
    Client client = (Client) visitor;
    boolean hasCompanion = client.hasCompanion();
    // other logic
}

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

Идея 4 : пересмотреть дизайн и реорганизовать дерево типов и то, как код использует наследование. Если нет смысла вызывать hasCompanion на Companion extends Visitor, почему hasCompanion является методом Visitor вообще?

Java не поддерживает множественное наследование, поэтому необходимы интерфейсы:

public interface MightHaveCompanion {
    public boolean hasCompanion();
}

public abstract class Visitor {
    // methods that all Visitors must have
}

public class Client extends Visitor implements MightHaveCompanion {
    // overriding implementations of MightHaveCompanion and Visitor methods 
}

public class Companion extends Visitor {
    // overriding implementations of Visitor methods
}

Тогда вызывающий код должен будет измениться, чтобы использовать типы MightHaveCompanion или Visitor по мере необходимости. Понятно, какие методы принадлежат к каким типам. Не заблуждайтесь, что в больших проектах объем работы для этого будет масштабироваться, но это может привести к более чистому коду.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...