Java Связь между интерфейсами/абстрактными классами

Question

Я пытаюсь построить алгоритм, который работает по-разному в зависимости от стратегии обхода и стратегии обновления . Однако не каждая стратегия обновления работает с каждой стратегией обхода. Следовательно, я решил, что стратегия обновления должна быть создана только с соответствующей стратегией прохождения. Я хотел создать для этого конструктор (см. Ниже). Чтобы подклассы должны были проверить, поддерживают ли они эту стратегию.

я в настоящее время имеющий интерфейс

public interface TraversalStrategy { 
... 
} 

И в (недопустимый) абстрактный класс

public abstract class UpdateStrategy { 
protected TraversalStrategy travStrategy; 

public abstract UpdateStrategy(TraversalStrategy travStrategy); 
} 

Что такое правильный способ подразумевает такую ​​зависимость? Я мог бы, конечно, добавить к этому конструктору пустое тело, но это показалось мне неправильным.

Update: Вдохновленный Ответ @Kayaman, я создал новый класс TestcaseGenerator, который используется для построения правильного сочетания.

public TestcaseGenerator(TraversalStrategy travStrategy, UpdateStrategy updStrategy){ 
    if (updStrategy.supports(travStrategy)){ 
     this.travStrategy = travStrategy; 
     this.updStrategy = updStrategy; 
    } 
} 

Что мне не нравится об этом еще есть, что теперь было бы излишним, чтобы дать экземпляр TraversalStrategy к UpdateStrategy, чтобы проверить, если она поддерживается. Я бы предпочел только имя класса. Можете ли вы рассказать мне, как достичь этого? Эксперименты с .getClass().getName() казались ужасными. В настоящее время я делаю:

public boolean supports(TraversalStrategy travStrategy){ 
    if(travStrategy instanceof UpstreamTraversalStrategy){ 
     return true; 
    } 
    return false; 
} 

Answer 1

Один из распространенных способов, чтобы иметь суперкласс вызова конструктора абстрактный метод такой, как isSupported(TraversalStrategy t); и потерпеть неудачу, если это не так.

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

Одним из подходов было бы создание третьего класса с использованием шаблона Builder. Вместо предоставления TraversalStrategy в качестве параметра UpdateStrategy они оба будут включены в третий объект (и их можно было бы проверить на build(), чтобы предотвратить несовместимые стратегии).

Тогда вы могли бы иметь общую функциональность в третьем классе, при этом классы стратегий становятся легче.

Answer 2

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