Несколько дней долбился в эти шаблоны. В книге Мэтта Зандстра, в нескольких видеороликах на Ютубе, на Хабре. Только благодаря этой записи я смог понять. У Вас талант. Спасибо. Надеюсь, найду у Вас на канале видео и по другим шаблонам
35:00 :) Потом удивляемся, почему температура на улице +3, а сам сосульки из носа достаешь) P.S. видео огонь, с удовольствием посмотрел. Очень жаль, что больше ничего подобного нет.
В патерне state тоже есть куча ифов )) И код получился более громоздким. ) Реализуйте через switch или через result $stateName ? $this->$stateName() : $this->defaultStateName() ))) Тема не раскрыта, зачем такой костыль. Код ради кода?
По паттерну состояние осталось непонятно - а что происходит с объектами состояний при переходе в другое состояние. Например объект инвойса перешел в состояние Draft а затем в состояние Approve, но что с объектом Draftр он не уничтожается?
Вопрос по адаптеру. А не логичнее ли не создавать отдельный класс USWeatherAdapter, который работает по интефейсу WeatherService, а написать, допустим, новый класс WorldWeather, который бы работал по интерфейсу WeatherService, но умел бы работать и с Россией и Америкой? Ведь чтобы сейчас этот код использовать, мы должны заранее в коде знать, по российскому мы городу хотим получить данные, или по американскому., а это неудобно. Не правильнее ли просто запросить данные по городу, и пусть методы сами разбираются, есть у них такой город хоть в каком-то функционале, или нет, и возвращают по нему данные, если найдут?
Могу ошибаться. Но мне кажется, что в таком случае мы смешаем обязанности в WorldWeather. WorldWeather будет в таком случае работать и как Адаптер и как агрегатов различных сервисов( американских, российских и т.д.). Мне кажется, в классе-агрегаторе WorldWeather есть смысл, но USWeatherServiceAdapter в нем нам тоже пригодится, чтобы был единый интерфейс работы со всеми сервисами. Т. е. чтобы мы в классе WorldWeather не решали задачу, что нам нужно переводить температуру из одной единицы измерения в другую. Просто в ролике автор пытается рассказать смысл именно паттерна Adapter, поэтому о дополнительных возможных не упоминал.
Удивительно, никакого монтажа, спецэффектов и мемов, а только теория и примеры по делу. Зашло лучше, чем все видео об околопаттерновой теме. Спасибо!
Несколько дней долбился в эти шаблоны. В книге Мэтта Зандстра, в нескольких видеороликах на Ютубе, на Хабре. Только благодаря этой записи я смог понять. У Вас талант. Спасибо. Надеюсь, найду у Вас на канале видео и по другим шаблонам
Последний прям "сложна". Синглтон знал, а про Адаптер очень полезно
Да, очень интересно смотрится!
Супер, разобрался наконец то!!!
прекрасний семінар, отримав величезне задоволення від перегляду. подача на найвищому рівні!
35:00 :) Потом удивляемся, почему температура на улице +3, а сам сосульки из носа достаешь)
P.S. видео огонь, с удовольствием посмотрел. Очень жаль, что больше ничего подобного нет.
Божественний урок!!
В патерне state тоже есть куча ифов )) И код получился более громоздким. )
Реализуйте через switch
или через
result $stateName ? $this->$stateName() : $this->defaultStateName() )))
Тема не раскрыта, зачем такой костыль. Код ради кода?
По паттерну состояние осталось непонятно - а что происходит с объектами состояний при переходе в другое состояние. Например объект инвойса перешел в состояние Draft а затем в состояние Approve, но что с объектом Draftр он не уничтожается?
37:00 паттерн state - состояние
Вопрос по адаптеру. А не логичнее ли не создавать отдельный класс USWeatherAdapter, который работает по интефейсу WeatherService, а написать, допустим, новый класс WorldWeather, который бы работал по интерфейсу WeatherService, но умел бы работать и с Россией и Америкой? Ведь чтобы сейчас этот код использовать, мы должны заранее в коде знать, по российскому мы городу хотим получить данные, или по американскому., а это неудобно. Не правильнее ли просто запросить данные по городу, и пусть методы сами разбираются, есть у них такой город хоть в каком-то функционале, или нет, и возвращают по нему данные, если найдут?
Могу ошибаться. Но мне кажется, что в таком случае мы смешаем обязанности в WorldWeather. WorldWeather будет в таком случае работать и как Адаптер и как агрегатов различных сервисов( американских, российских и т.д.). Мне кажется, в классе-агрегаторе WorldWeather есть смысл, но USWeatherServiceAdapter в нем нам тоже пригодится, чтобы был единый интерфейс работы со всеми сервисами. Т. е. чтобы мы в классе WorldWeather не решали задачу, что нам нужно переводить температуру из одной единицы измерения в другую. Просто в ролике автор пытается рассказать смысл именно паттерна Adapter, поэтому о дополнительных возможных не упоминал.
Не очень понятный пример с состоянием. Много вопросов возникает к его реализации.
19:00 паттерн Адаптер
На видео 28.06.2019
Сейчас 29.06.2019
Мне потребовалось чуть больше года, чтобы найти этот хороший ролик. С запозданием говорю спасибо автору)
год?
А по остальным паттернам есть видео у вас?
State слишком сложно.