Нормально. Шрифт можно побольше. Со смартфона код плохо видно. Хотя и без кода нормально. Интересно, а с каких устройств подписчики смотрят? P.S. это не критика, но обратная связь и комментарий для продвижения, которыми подписчики не балуют, пока ;) P.P.S. но шрифт действительно можно покрупнее.. P.P.P.S. вообще, объяснение паттерна на единственном примере черевата тем, что студент "фиксируется" на этом примере и конкретика подменяет ему абстракцию. Тут можно было-бы с тем-же шаблоном обыграть адаптер для печати отчёта на разные устройства. Просто мысли вслух ;)
Спасибо за обратную связь. источник трафика не секрет, 70/30 компьютер/мобильные устройства. По шрифту пометил в чеклист. В ролике были небольшие проблемы с рендерингом, код получился размытым. Постараюсь исправить в следующем паттерне. это кстати скажу по секрету, будет "Прототип". Да вы правы, используется конкретный пример, а не абстракция. мне хотелось в видео донести пользу паттерна, реальный пример использования, потому что после просмотра объяснения из википедии у людей часто возникают вопросы "ок, и где мне это пригодится?". мой ролик можно сказать дополняет академическое описание для тех кто ищет озарения в плане паттернов:)
Спасибо большое за видео, приятно слушать, а для учителя это главное! Теперь хочется пересмотреть свой код, кажется этот паттерн можно много где применить. А что скажите вы могут ли возникнуть проблемы из-за перенасыщения адаптерами?
Скажите, а если у вас приходят разные атрибуты для одной сущности? Если в ваших Reports у одного будет поле "name" , а в другом "full_name" или "p_name". Нужен ли какой-то паттерн или просто мапить через массив ['name' => 'p_name'] ? При API интеграции часто бывает, что наименование полей различное.
Так же в адаптере можете привести все результаты к одному виду или вынести логику в оделенный класс, если собираетесь приведение к виду использовать еще где то.
Спасибо. Интересно. Подобное применяю при загрузке прайсов от поставщика. У них разные форматы и разные данные. Сейчас там уже больше 30 таких адаптеров. Еще эта реализация попадается без ООП, на JS, где используют функции вместо классов. А что делать когда будут появляться адаптеры практически идентичные? Например порядок полей другой или кодировка.
Привет, спасибо! вопрос в том что считать идентичностью, цель адаптера только предоставить совместимость несовместимых объектов. Если предполагается сложная конфигурация можно сочетать со Строителем
Последняя фраза "несовместимые объекты никак не связаны с адаптерами, которые их принимают" некорректна. Адаптер и несовместимый объект связаны между собой отношениями агрегации.
Вы посмотрите шире на решение. Не в рамках этой задачи, а в рамках подхода. Вы делаете поведение предсказуемым, от чего с кодом работать проще как вам, так и другим разработчикам. Или вы бы хотели что бы автор показывал вам часовое видео (30-40 минут интро в приложение + 20 минут толковал как работает паттерн) на большом отрезке кода?
Поддержать автора 👨💻 :
Тинькофф www.tinkoff.ru/rm/sardyko.ivan2/DxuTY29617
Сбер 4274 3200 7445 1066
Спасибо. Полезная инфа для разработки
у вас отлично получается. было бы не плохо увидеть и остальные паттерны. необязательно все. но самые ходовые: цепочка, прокси, диай и тд
Нормально. Шрифт можно побольше. Со смартфона код плохо видно. Хотя и без кода нормально. Интересно, а с каких устройств подписчики смотрят?
P.S. это не критика, но обратная связь и комментарий для продвижения, которыми подписчики не балуют, пока ;)
P.P.S. но шрифт действительно можно покрупнее..
P.P.P.S. вообще, объяснение паттерна на единственном примере черевата тем, что студент "фиксируется" на этом примере и конкретика подменяет ему абстракцию. Тут можно было-бы с тем-же шаблоном обыграть адаптер для печати отчёта на разные устройства. Просто мысли вслух ;)
Спасибо за обратную связь. источник трафика не секрет, 70/30 компьютер/мобильные устройства. По шрифту пометил в чеклист. В ролике были небольшие проблемы с рендерингом, код получился размытым. Постараюсь исправить в следующем паттерне. это кстати скажу по секрету, будет "Прототип". Да вы правы, используется конкретный пример, а не абстракция. мне хотелось в видео донести пользу паттерна, реальный пример использования, потому что после просмотра объяснения из википедии у людей часто возникают вопросы "ок, и где мне это пригодится?". мой ролик можно сказать дополняет академическое описание для тех кто ищет озарения в плане паттернов:)
Спасибо большое за видео, приятно слушать, а для учителя это главное! Теперь хочется пересмотреть свой код, кажется этот паттерн можно много где применить. А что скажите вы могут ли возникнуть проблемы из-за перенасыщения адаптерами?
Скажите, а если у вас приходят разные атрибуты для одной сущности? Если в ваших Reports у одного будет поле "name" , а в другом "full_name" или "p_name". Нужен ли какой-то паттерн или просто мапить через массив ['name' => 'p_name'] ? При API интеграции часто бывает, что наименование полей различное.
Так же в адаптере можете привести все результаты к одному виду или вынести логику в оделенный класс, если собираетесь приведение к виду использовать еще где то.
Спасибо. Интересно. Подобное применяю при загрузке прайсов от поставщика. У них разные форматы и разные данные. Сейчас там уже больше 30 таких адаптеров. Еще эта реализация попадается без ООП, на JS, где используют функции вместо классов. А что делать когда будут появляться адаптеры практически идентичные? Например порядок полей другой или кодировка.
Привет, спасибо! вопрос в том что считать идентичностью, цель адаптера только предоставить совместимость несовместимых объектов. Если предполагается сложная конфигурация можно сочетать со Строителем
Раньше это называлось оберткой.
если $reportData = null will be Error
Последняя фраза "несовместимые объекты никак не связаны с адаптерами, которые их принимают" некорректна. Адаптер и несовместимый объект связаны между собой отношениями агрегации.
Слишком мелко, масштаб бы побольше, на ноуте ни черта не видно.
да, есть такое. изменю размер шрифта в следующих роликах
Полная хрень..... Ничего толком не изменилось.. только стало больше кода и файлов, те самые кучи ифов и elseif🤢
Вы посмотрите шире на решение. Не в рамках этой задачи, а в рамках подхода. Вы делаете поведение предсказуемым, от чего с кодом работать проще как вам, так и другим разработчикам. Или вы бы хотели что бы автор показывал вам часовое видео (30-40 минут интро в приложение + 20 минут толковал как работает паттерн) на большом отрезке кода?