Что (не) объявить при реализации интерфейса с абстрактным классом?

Question

У меня есть интерфейс A, для которого я должен предоставить несколько различных реализаций . Однако эти реализации используют некоторые вспомогательные методы, поэтому Я переместил эти методы в абстрактный базовый класс.

Interface A { 
    void doX(); 
} 

abstract Class B implements A { 
    protected void commonY() { 
     // ... 
    } 

    @Override 
    public abstract void doX(); 
} 

Class C extends B { 
    @Override 
    public void doX() { 
     // ... 
    } 
} 

Class D extends B { 
    @Override 
    public void doX() { 
     // ... 
    } 
} 

Мой код работает, как ожидалось, но у меня есть несколько вопросов:

• Должен ли я объявить абстрактный метод DOX() в классе B? Почему нет)?

• Должен ли я также явно объявлять «реализует A» в классах C и D? Почему нет)?

Answer 1

Я думаю, что было бы лучше сделать это следующим образом:

Interface A { 
     void doX(); 
} 

abstract Class B { 
     protected void commonY() { 
       // ... 
     } 
} 

Class C extends B implements A{ 

     public void doX() { 
       // ... 
     } 
} 

Class D extends B implements A{ 

     public void doX() { 
       // ... 
     } 
} 

Не следует смешивать интерфейс (подпись методов) с реализацией.

Answer 2

• Должен ли я объявить абстрактный метод DOX() в классе B? Почему нет)?

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

• Должен ли я также явно объявлять «реализует A» на классах C и D? Почему нет)?

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

Answer 3

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

Наследование транзитивно. Вам не нужно писать, что класс C реализует интерфейс A, если класс C выводит класс B, который реализует интерфейс A. Однако для него также не так много вреда.

Answer 4

я бы не объявить doX() в B и не добавить «implements A» на C и D, потому что вы должны not repeat yourself.

Реферат doX() в B ничего не добавляет, как это уже указано «implements A». То же самое верно для добавления «implements A» на C и D.

Единственное возможное использование этих положений будет документация: Если вы хотите сделать это очень четко указано, что C (или D) является разновидностью A, то вы можете добавить implements, но вы должны знать, что это действительно Безразлично Не имеет значения для компилятора.

Answer 5

Я просто поставлю другой вариант.

Включить абстрактный класс B в класс AUtil, который не реализует A. Для сигнатур метода может потребоваться дополнительный аргумент типа A для работы.

C и D реализуют A и создают экземпляр AUtil внутри. Это позволяет C и D расширять другие классы.

Answer 6

Я согласен с JeeBee: рассмотрите возможность реализации ваших вспомогательных методов где-то, кроме абстрактного базового класса.

Если ваш вспомогательный метод commonY() существует только в абстрактном базовом классе B, все классы, реализующие интерфейс A, должны также расширить базовый класс B, чтобы воспользоваться этой реализацией commonY(). Но вы не всегда можете быть вынуждены продлить класс B.

Также, если вы хотите изменить реализацию commonY() в будущем? Затем вы затронете множество реализаций интерфейса A. Но если вы не контролируете все эти реализации интерфейса A, вы можете повлиять на их функциональность (плохой), не намереваясь.

Использование абстрактного базового класса в этой ситуации может просто устранить некоторую гибкость, не давая вам ничего взамен.