Меню
Что нового?

Наследование интерфейсов

  • Автор темы Автор темы Adelf
  • Дата начала Дата начала
Наследование интерфейса от интерфейса - это обычная практика и ничего тут удивительного нет :) Полиморфизм рулит. Примеров куча. К примеру, ну не хочу я писать тысячу перехватчиков исключений, тогда как я могу грамотно их сгруппировать.
 
Да зачем тут код. Еще один пример группировки интерфейсов. Чтобы у множества классов каждый раз не прописывать все интерфейсы (Class A implements B, C, D), от которых он наследуется, делается базовый интерфейс, от которого наследуются другие. Классы же в итоге реализуют интерфейсы N-о уровня (уровней немного обычно). Да, согласен, что, обычно, проще реализовать стратегию, но все зависит от ситуации.

И еще. Вы писали "Хочу interface A implements B, C". Через extends имели ввиду, наверное.
 
Adelf написал(а):
Покажи-ка нам кодом, что ты имеешь ввиду?
Нажмите для раскрытия...
Он имеет в виду типа https://github.com/symfony/symfony/...ncyInjection/Exception/ExceptionInterface.php
Ты можешь ловить исключения конкретно этого компонента.
Но на практике я такое не люблю.
Я не вижу никакой пользы от того, что буду ловить какое-то общее событие.
Либо ловлю сразу \Exception или \Throwable, если я хочу предотвратить падение программы, либо вполне конкретное, где я точно понимаю что произошло и могу предпринять какое-то вполне конкретное действие.
А то знания что что-то пошло не так конкретно в DIC мне ни жарко ни холодно.
 
Вурдалак написал(а):
Он имеет в виду типа https://github.com/symfony/symfony/...ncyInjection/Exception/ExceptionInterface.php
Ты можешь ловить исключения конкретно этого компонента.
Но на практике я такое не люблю.
Я не вижу никакой пользы от того, что буду ловить какое-то общее событие.
Либо ловлю сразу \Exception или \Throwable, если я хочу предотвратить падение программы, либо вполне конкретное, где я точно понимаю что произошло и могу предпринять какое-то вполне конкретное действие.
А то знания что что-то пошло не так конкретно в DIC мне ни жарко ни холодно.
Нажмите для раскрытия...


Если у тебя обработка заключается в чем-то одном, то да, ты можешь просто один обработчик сделать. А вот если у тебя должны быть разные обработчики, тогда нужно ловить несколькими обработчиками.
 
Codwondo написал(а):
Если у тебя обработка заключается в чем-то одном, то да, ты можешь просто один обработчик сделать. А вот если у тебя должны быть разные обработчики, тогда нужно ловить несколькими обработчиками.
Нажмите для раскрытия...
«Папа, ты мне как отец»
 
Да при чём тут задеть.
Ты пургу гонишь, сам того не понимая, и не пытаешься вчитаться в то, что тебе люди отвечают.
Исключения создаются не для обработчиков, а для тебя, чтобы обратил внимание на проблему.
Будешь ты её "обрабатывать" или нет, никому не интересно.
 
Вурдалак написал(а):
Он имеет в виду типа https://github.com/symfony/symfony/...ncyInjection/Exception/ExceptionInterface.php
Нажмите для раскрытия...
Не в тему, но меня так порадовало, что у пустого интерфейса два автора :)

Я почему-то думал, что @Codwondo хочет интерфейсы исключений наследовать от нескольких. И очень хотел на такой кейс посмотреть. Оказывается обычное наследование. Тогда все ок.
 
Codwondo написал(а):
множества классов каждый раз не прописывать все интерфейсы (Class A implements B, C, D), от которых он наследуется
Нажмите для раскрытия...
про наследование классов от интерфейсов все примерно понятно. Осталось выяснить, каким боком и главное зачем примотали "многоуровневые" (даже не смотря на то, что уровней обычно не много) интерфейсы к исключениям.
Наверное, это будет что-то стоящее, раз поднял тему полуторагодичной давности.
Если ответ секретный, могу указать промокод для своих PHPCLUBRU
 
Войдите или зарегистрируйтесь для ответа.
Сверху