-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Dima_u
Guest
Не думал по этому поводу.
Если про яву, то там и обработчик событий ( mouselistener, eventlistener...) можно через интерфейс получить. ( и многое другое.. достаточно много нужных возможностей)
Я в структуре работы vm не очень шарю, может быть и так как ты сказал.
Если про яву, то там и обработчик событий ( mouselistener, eventlistener...) можно через интерфейс получить. ( и многое другое.. достаточно много нужных возможностей)
Я в структуре работы vm не очень шарю, может быть и так как ты сказал.
Dima_u
Guest
нет,я знаю что это такое, это мне не надо объяснять.
Я не очень понял что neko пытался сказать.
Я не очень понял что neko пытался сказать.
Dima_u
Guest
Интерфейсы разве не являются структурой ООП?
neko
tеam neko
я пытался сказать
что если мы хотим, например, сделать arrayaccess
то интерфейс имеет смысл
но функционал который будет тем самым доступен
реализован не на пхп, а чуть в другой плоскости
-~{}~ 04.02.05 02:13:
которому в разных языках соответствуют разные понятия
что если мы хотим, например, сделать arrayaccess
то интерфейс имеет смысл
но функционал который будет тем самым доступен
реализован не на пхп, а чуть в другой плоскости
-~{}~ 04.02.05 02:13:
это прежде всего слово
которому в разных языках соответствуют разные понятия
wrapper
Guest
Dima_u, neko
несколько примеров использования интерфейсов
1. постановка задачи
ты лидер команды разработчиков. нужно реализовать add/edit/delete/list в
БД обьекта Person. Что бы не обьяснять это на словах, ты просто пишешь интерфейс и даешь задание его реализовать.
Причем еще до реализации его он может быть использован другими разработчиками ( быстро делается простейшая временная реализация )
2. избегание прямых зависимостей
если система проектируется по модульному принципу, то каждый из модулей может предоставлять какой-то свой АПИ, который не привязан к конкретной реализации, т.е. интерфейсы. При переработке модуля, замене его классов, другие модули этого не почувствуют т.к. они работают с его интерфейсом
3. тестирование
применение п.2
модуль регистрации использует модуль рассылки почты
для тетсирования модуля регистрации делается mock- реализациия интерфеса почтового модуля
несколько примеров использования интерфейсов
1. постановка задачи
ты лидер команды разработчиков. нужно реализовать add/edit/delete/list в
БД обьекта Person. Что бы не обьяснять это на словах, ты просто пишешь интерфейс и даешь задание его реализовать.
Причем еще до реализации его он может быть использован другими разработчиками ( быстро делается простейшая временная реализация )
2. избегание прямых зависимостей
если система проектируется по модульному принципу, то каждый из модулей может предоставлять какой-то свой АПИ, который не привязан к конкретной реализации, т.е. интерфейсы. При переработке модуля, замене его классов, другие модули этого не почувствуют т.к. они работают с его интерфейсом
3. тестирование
применение п.2
модуль регистрации использует модуль рассылки почты
для тетсирования модуля регистрации делается mock- реализациия интерфеса почтового модуля
Gas
может по одной?
wrapper
Guest
Gas
это я о интерфейсах которые являются частью ООП
а как ты себе видишь их применение?
это я о интерфейсах которые являются частью ООП
а как ты себе видишь их применение?
Gas
может по одной?
wrapper
п.1 - имхо может сделать какой-то базовый класс, от которого наследуется Person и в котором есть реализация этих методов по умолчанию. Так как это типовые операции, которые часто у разных классов реализацией не отличаются.
п.2 - Есть модуль новости и модуль комментарии. Не понимаю как тут можно интерфейсы поиспользовать.
Ты имеешь ввиду "интерфейс класса" - совокупность его публичных методов?
п.3 - Не совсем понял как. Агрегировать в объект регистрации объект рассылки, понимаю. Но как помогут тут интерфейсы?
То-есть iMail это интерфейс, и есть Mail_SMTP implement iMail и Mail_SMTP_Mock implement iMail, один из обектов передаётся/создаётся в регистрации. Так?
Если так, то не вижу в данном случае _для тестирования_ (не системы рассылки) разницы что юзать интерфейсы или абстрактый класс.
п.1 - имхо может сделать какой-то базовый класс, от которого наследуется Person и в котором есть реализация этих методов по умолчанию. Так как это типовые операции, которые часто у разных классов реализацией не отличаются.
п.2 - Есть модуль новости и модуль комментарии. Не понимаю как тут можно интерфейсы поиспользовать.
Ты имеешь ввиду "интерфейс класса" - совокупность его публичных методов?
п.3 - Не совсем понял как. Агрегировать в объект регистрации объект рассылки, понимаю. Но как помогут тут интерфейсы?
То-есть iMail это интерфейс, и есть Mail_SMTP implement iMail и Mail_SMTP_Mock implement iMail, один из обектов передаётся/создаётся в регистрации. Так?
Если так, то не вижу в данном случае _для тестирования_ (не системы рассылки) разницы что юзать интерфейсы или абстрактый класс.
wrapper
Guest
п.1 - это пример, то же самое может касаться любой функциональности, не только сохранения
п.2
модуль может состоять как из одного так и скольки угодно классов или либ
но разумно выделить ту часть функциональности с которой будут взаимодействовать другие модули. И сделать для нее интерфейс.
п.3
в приложении мы передаем Mail_SMTP модулю регистрации чтобы он мог работать
но если мы хотим протестировать модуль регистрации, не нужно ему прередавать "настоящий" модуль рассылки
мы передаем ему Mock который на самом деле и письма то не умеет отправлять, зато прекрасно регистрирует все обращения к нему со стороны модуля регистрации
а чтобы мы могли так поступить, модуль регистрации должен зависеть от _интерфейса_ модуля рассылки (iMail) а не от конкретной реализации (Mail_SMTP)
п.2
нет
модуль может состоять как из одного так и скольки угодно классов или либ
но разумно выделить ту часть функциональности с которой будут взаимодействовать другие модули. И сделать для нее интерфейс.
п.3
так
в приложении мы передаем Mail_SMTP модулю регистрации чтобы он мог работать
но если мы хотим протестировать модуль регистрации, не нужно ему прередавать "настоящий" модуль рассылки
мы передаем ему Mock который на самом деле и письма то не умеет отправлять, зато прекрасно регистрирует все обращения к нему со стороны модуля регистрации
а чтобы мы могли так поступить, модуль регистрации должен зависеть от _интерфейса_ модуля рассылки (iMail) а не от конкретной реализации (Mail_SMTP)
Gas
может по одной?
п.1 - ладно, всё сильно зависит от задачи, абстрактно об этом говорить думаю не имеет смысла.
п.2 - можешь привети пример? Вот этого я не понимаю. Если много классов понимаю сделать фасад к модулю (Facade pattern). Но как может интерфейс помочь?
п.3 - имхо, в общем случае тут без разницы. Хоть интерфейс, хоть абстрактный класс (АК). Но у АК есть преимущество если нужна общая функциональность для всех потомков. Например, вести логи и при реальной отправке почты и при отсылке работе с Mock.
Я не пытаюст тебя в чём-то убедить, сам разобраться хочу
Просто мне кажется в твоих примерах можно использовать хоть интерфейсы, хоть АК без особой разницы.
п.2 - можешь привети пример? Вот этого я не понимаю. Если много классов понимаю сделать фасад к модулю (Facade pattern). Но как может интерфейс помочь?
п.3 - имхо, в общем случае тут без разницы. Хоть интерфейс, хоть абстрактный класс (АК). Но у АК есть преимущество если нужна общая функциональность для всех потомков. Например, вести логи и при реальной отправке почты и при отсылке работе с Mock.
Я не пытаюст тебя в чём-то убедить, сам разобраться хочу
Просто мне кажется в твоих примерах можно использовать хоть интерфейсы, хоть АК без особой разницы.
wrapper
Guest
блин, случайно энтер нажал,
сейчас отвечу
-~{}~ 04.02.05 20:15:
....устал уже
фиг с ними с моими примерами
на пхп сейчас не пишу, devil in details, сдаюсь
сейчас отвечу
-~{}~ 04.02.05 20:15:
....устал уже
фиг с ними с моими примерами
на пхп сейчас не пишу, devil in details, сдаюсь