В каждом примере, который я видел, расширенные классы реализуют интерфейсы своих родителей. Для справки, следующий пример:
interface MyInterface{ public function foo(); public function bar(); } abstract class MyAbstract implements MyInterface{ public function foo(){ /* stuff */ } public function bar(){ /* stuff */ } } // what i usually see class MyClass extends MyAbstract implements MyInterface{} // what i'm curious about class MyOtherClass extends MyAbstract{} Не удается ли реализовать интерфейс в дочернем элементе, который реализуется родителем, считается плохой практикой или чем-то еще? Существуют ли какие-либо технические недостатки для отказа от реализации в ребенке?
Я бы подумал, что вы на правильном пути. Нет необходимости заявлять, что вы реализуете интерфейс, когда расширяете класс, который уже implements его. Для меня это просто еще один код для поддержки, если необходимо изменить. Итак, да, вы правы!
Не удается ли реализовать интерфейс в дочернем элементе, который реализуется родителем, считается плохой практикой или чем-то еще? Существуют ли какие-либо технические недостатки для отказа от реализации в ребенке?
Я просто не могу ответить на ваш вопрос лучше, чем этот парень:
По своей природе, хотя иногда они могут выглядеть довольно схожими, абстрактные классы и интерфейсы классов служат очень различным целям.
Интерфейс класса подразумевается как инструмент для «пользователя» этого класса. Интерфейс представляет собой публичную презентацию для класса, и он должен рекламировать любого, кто хочет использовать его, какие методы и константы доступны и доступны извне. Таким образом, как следует из названия, он всегда находится между пользователем и классом, реализующим его.
С другой стороны, абстрактный класс является инструментом, помогающим «разработчику» классов, которые его расширяют. Это инфраструктура, которая может налагать ограничения и рекомендации относительно того, как должны выглядеть конкретные классы. С точки зрения дизайна класса абстрактные классы более архитектурно важны, чем интерфейсы. В этом случае разработчик сидит между абстрактным классом и конкретным, создавая последний поверх первого.
Справка
Таким образом, вам решать, основываясь на том, кто будет использовать (создавать экземпляры) ваши классы, и кто будет писать их. Если вы единственный пользователь и писатель своих классов, то, может быть, просто, может быть, вам не нужны оба. Но, если вы хотите дать каждому урезанный план основных битов для писателей (ов) класса и пользователей класса, то вам следует рассмотреть возможность использования как абстрагирования, так и реализации.
Не удается ли реализовать интерфейс в дочернем элементе, который реализуется родителем, считается плохой практикой или чем-то еще?
Ребенок всегда реализует интерфейс, он не может обойти это.
Я понятия не имею, если это плохая практика или что-то в этом роде. Я бы сказал, что это язык.
Существуют ли какие-либо технические недостатки для отказа от реализации в ребенке?
Вы не можете проверить отражение абстрактного класса для интерфейса, например.
Тем не менее, абстрактный класс уже является интерфейсом, поэтому технически они сами по себе не нуждаются в интерфейсе, но вы можете сделать это, чтобы держать вещи в пределах наследства.