Что (не) объявить при реализации интерфейса с абстрактным классом?
Это потому, что вы делаете разделитель длиной 3 символа ' + \t + ' вместо одного \t.
Попробуйте:
a="\t"
my_line.split(a)
6 ответов
Я думаю, что было бы лучше сделать это следующим образом:
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() {
// ...
}
}
Вы не должны смешивать интерфейс (подпись методов) с реализацией.
- Я должен объявить абстрактный метод doX () в Классе B? Почему (нет)?
Нет. Это - абстрактный класс - определение интерфейса будет означать, что все подклассы должны будут реализовать те методы. Другими словами, это избыточно.
- Я должен также явно объявить "реализации" на Классе C и D? Почему (нет)?
Нет, снова - потому что Ваш суперкласс (Абстрактный базовый класс) реализации, которые взаимодействуют через интерфейс, Ваши конкретные подклассы, как будут гарантировать, реализует тот интерфейс.
Я просто добавлю другую опцию.
Превратите абстрактный класс B в класс AUtil, который не реализует A. Сигнатуры методов могут потребовать, чтобы дополнительный аргумент типа A работал с.
C и D реализуют A и инстанцируют AUtil внутренне. Это действительно позволяет C и D расширять другие классы.
Я соглашаюсь с JeeBee: рассмотрите реализацию Ваших вспомогательных методов где-нибудь кроме абстрактного базового класса.
Если Ваш вспомогательный метод commonY () только существует в абстрактном базовом классе B, все классы, которые реализуют Интерфейс A, должны будут также расширить базовый класс B для использования в своих интересах той реализации commonY (). Но, Вы не могли бы всегда хотеть быть вынужденными расширить класс B.
Кроме того, что, если Вы хотите изменить реализацию commonY () в будущем? Вы будете затем влиять на большое количество реализаций интерфейса A. Но если Вы не управляете всеми этими реализациями интерфейса A, можно влиять на их функциональность (плохим способом), не предназначая к.
Используя абстрактный базовый класс в этой ситуации может просто устранить некоторую гибкость, ничего не давая Вам в ответ.
Абстрактный класс, реализовывая интерфейс должен реализовать тот интерфейс. А именно, это должно иметь открытый метод для каждого method-name-and-signature, указанного в том интерфейсе.
Наследование является переходным. Вы не должны писать, что реализации класса C взаимодействуют через интерфейс, если класс C получает класс B, который реализует интерфейс A. Однако нет большого вреда ему также.
Я не объявил бы doX() в B и не добавляют"implements A"на C и D потому что Вы не должны повторять себя.
Краткий обзор doX() в B не добавляет ничто, поскольку это уже указано"implements A". То же верно для добавления"implements A"к C и D.
Единственное возможное применение для тех пунктов было бы документацией: Если Вы хотите сделать это очень явным это C (или D) - a A, затем Вы могли добавить implements, но необходимо знать, что это действительно не имеет значения для компилятора.