Меньше верь всему... Один хайпажер решил рассказать, другие подхватили и побнесли в массы как истину в последней инстанции... ) Все что можно и нельзя описано в документации. Остальное видение отдельных разработчиков для холиваров, а не аксиома.
Бро, нужно больше таких видео, очень информативно и подача на высоте, не забрасывай это дело, прошу. Сейчас сам почти миддл уровня достиг в php, но подобные ролики про пхп заставляют вспоминать то, что забыто, но важно
что поменялось в примере на 6-й минуте? мы защитили класс от изменений? нет. так же можем менять, но теперь через методы. мы добавили слой абстракции? да, но зачем? практика сеттеров и геттеров в таком примере определенно плоха, наши методы не обеспечивают ничего, кроме более легкого поиска в проекте. понравилось, что в следующем примере объясняется про солид, и на тебе - логин, который валидирует введенный текст, что нарушает первый принцип. да еще и без комментария о том, как работает регулярка (комментарии до этого мы же считаем не нужными). про следующий пример, который пользователя регистрирует по логину я уж молчу) в последнем примере тоже красота. красивые слова об open-closed, дескать создадим отдельный класс, а не массив, чтобы не менять функцию логина. ну создали, ок. а если в классе ошибки появится еще какое-то поле, мы точно не изменим метод логина? изменим) опять де молчу про то, что в классе Error, содержится переменная error, которая может быть true или false. надеюсь, что за два года с момента публикации этого ролика, автор стал чуть ближе к пониманию того, такое солид и ооп
Может будет интересно рассказать в следующих роликах Зачем нужен ООП и всегда ли нужно прибегать к объектам? Коротенько предыстория, юзаю CMS, реализованы классы работы с БД (вкинуть и взять из бд), шаблонизатор (завернуть данные по шаблонам), кэш. Дописываю свои модули, юзаю исключительно обычные функции, в функциях вызываю другие свои функции и дефолтные классы цмски и не понимаю как, а главное зачем мне новые классы, инкапсуляции и прочие принципы ООП?
Хороший урок! Извините, но я бы посоветовал использовать метод setAge(int $age) {} Это хорошая практика на мой взгляд. Упрощать код всегда хорошо, но и в частности наименований. Сэкономит ещë 2 секунды.
Здравствуйте, подскажите как вы считаете стоит ли забивать Контейнер классами хелперами которые содержат например один статический метод (который просто умножает приходящие к нему числа)?
Если метод статический, то добавление классов в контейнер сомнительное занятие. Выгода не понятна. Только, если есть цель использовать нечто похожее на фасады (facade) в laravel, но вроде вопрос не в этом ключе. В общем, обычно так не делаю сам. Можно обращаться к статическому методу напрямую, если мы говорим про PHP.
@@Владимир777-о9с Если метод статический, то добавление классов в контейнер сомнительное занятие. Выгода не понятна. Только, если есть цель использовать нечто похожее на фасады (facade) в laravel, но вроде вопрос не в этом ключе. В общем, обычно так не делаю сам. Можно обращаться к статическому методу напрямую, если мы говорим про PHP.
Идеально. Еще бы хотелось что-нибудь связанное с тестированием послушать от тебя. Codeception или PhpUnit. Как правильно организовывать интеграционные тесты, что есть фикстуры, стабы, моки и тд.
12:55 Так неправильно переписан пример :) В первом варианте у тебя метод всегда возвращает строку, а во втором может быть как строка, так и void. Если бы соблюдалась строгая типизация, ты бы тут же словил эксепшн. В остальном, всё гуд, новичкам будет полезно взять на заметку.
Крутое видео. Полезная инфа. Хотелось бы услышать от Вас примеры применения шаблонов проектирования из реальной жизни (без котиков и собачек). Выучил большинство шаблонов, вроде все понял, а при решении задач трудно начать внедрять их. P.S. Очки лишние.
Благодарю. Многие паттерны уже реализованы на уровне фреймворков и библиотек, но в верхне-уровнем коде тоже приходится применять. Материалов на данную тему в сети достаточно много, посмотрю на досуге, может какие-то темы еще не освещены. Спасибо!
Все хорошо, но не люблю когда демонстрируют примеры и говорят "ну так делать не нужно", а зачем ты это тогда показываешь? Показывайте на нормальных, реальных примерах, пусть будет сложнее, дольше, но за то реально чему то научит.
Беда в том, что так пишут люди которые не знают как правильно. К сожалению это не выдуманные примеры, это то с чем приходиться сталкиваться при ревью кода коллег. Вы всегда можете создать свой блог и выложить свой вариант примеров, которые вам кажутся более правильными.
Я думаю, что мы находимся на начале одного из самых популярных каналов в сфере веба в снг
спасибо, очень понятно и структурировано. А самое главное, как часто бывает - не занудно!)
Нужно больше рефакторинга. Видео плюс. Хочу ещё!
Продукт будет или только бесконечный рефакторинг? ) К 85 годам увидим продукт? )))
Думал скажешь банальщину из книжек, но я услышал для себя много неочевидных моментов) Спасибо
Очень круто, очень годно объясняете!
Ох, я только что узнал, что от моего кода, видимо, попахивает) Спасибо за видео. Очень информативно)
не больше, чем от кода автора)
Меньше верь всему... Один хайпажер решил рассказать, другие подхватили и побнесли в массы как истину в последней инстанции... )
Все что можно и нельзя описано в документации. Остальное видение отдельных разработчиков для холиваров, а не аксиома.
Привет, будет классно если канал будет развиватся, здесь все класно все професианально спасибо
Интересно, ждемс обсуждения
Красава, все правильно и четко объяснил
ничего правильного только)
Бро, нужно больше таких видео, очень информативно и подача на высоте, не забрасывай это дело, прошу. Сейчас сам почти миддл уровня достиг в php, но подобные ролики про пхп заставляют вспоминать то, что забыто, но важно
Андрей, спасибо за то, что делитесь опытом, очень познавательно, современно, не только по этому ролику сужу.
Сделать код на столько читабельным, что бы его нельзя было прочитать, не залезая в потроха. )
Вообще интересно.
Спасибо вам за ролик!!! Сам пишу на php, а подобных видео не хватает.
что поменялось в примере на 6-й минуте? мы защитили класс от изменений? нет. так же можем менять, но теперь через методы. мы добавили слой абстракции? да, но зачем? практика сеттеров и геттеров в таком примере определенно плоха, наши методы не обеспечивают ничего, кроме более легкого поиска в проекте.
понравилось, что в следующем примере объясняется про солид, и на тебе - логин, который валидирует введенный текст, что нарушает первый принцип. да еще и без комментария о том, как работает регулярка (комментарии до этого мы же считаем не нужными). про следующий пример, который пользователя регистрирует по логину я уж молчу)
в последнем примере тоже красота. красивые слова об open-closed, дескать создадим отдельный класс, а не массив, чтобы не менять функцию логина. ну создали, ок. а если в классе ошибки появится еще какое-то поле, мы точно не изменим метод логина? изменим) опять де молчу про то, что в классе Error, содержится переменная error, которая может быть true или false.
надеюсь, что за два года с момента публикации этого ролика, автор стал чуть ближе к пониманию того, такое солид и ооп
Інкапсуляція. Код як документація
12:55 нерівнозначна заміна. У першому випадку завжди буде помилка, у другому є сценарій без помилки
Очень толково, информативно и понятно. Спасибо. Хочу спросить, когда лучше использовать объекты, а когда простые функции?
если того требует применение абстракции
Может будет интересно рассказать в следующих роликах
Зачем нужен ООП и всегда ли нужно прибегать к объектам?
Коротенько предыстория, юзаю CMS, реализованы классы работы с БД (вкинуть и взять из бд), шаблонизатор (завернуть данные по шаблонам), кэш. Дописываю свои модули, юзаю исключительно обычные функции, в функциях вызываю другие свои функции и дефолтные классы цмски и не понимаю как, а главное зачем мне новые классы, инкапсуляции и прочие принципы ООП?
Хороший урок!
Извините, но я бы посоветовал использовать метод setAge(int $age) {}
Это хорошая практика на мой взгляд.
Упрощать код всегда хорошо, но и в частности наименований.
Сэкономит ещë 2 секунды.
это просто плохая практика
Здравствуйте, подскажите как вы считаете стоит ли забивать Контейнер классами хелперами которые содержат например один статический метод (который просто умножает приходящие к нему числа)?
Если метод статический, то добавление классов в контейнер сомнительное занятие. Выгода не понятна. Только, если есть цель использовать нечто похожее на фасады (facade) в laravel, но вроде вопрос не в этом ключе.
В общем, обычно так не делаю сам. Можно обращаться к статическому методу напрямую, если мы говорим про PHP.
интересно ваше мнение, надеюсь ответите не забудете)
@@Владимир777-о9с Если метод статический, то добавление классов в контейнер сомнительное занятие. Выгода не понятна. Только, если есть цель использовать нечто похожее на фасады (facade) в laravel, но вроде вопрос не в этом ключе.
В общем, обычно так не делаю сам. Можно обращаться к статическому методу напрямую, если мы говорим про PHP.
Это инфа из книг? Посоветуй первоисточники, откуда ты берёшь инфу
Идеально. Еще бы хотелось что-нибудь связанное с тестированием послушать от тебя. Codeception или PhpUnit. Как правильно организовывать интеграционные тесты, что есть фикстуры, стабы, моки и тд.
Немного вводной по теме unit тестирования: ua-cam.com/video/BGw-NVfZ1HI/v-deo.html
15:55 а класс какой длины? Бывает встречаю по 2к строк и даже по 4к.. Как по мне - лучше небольше 1к, больше - уже сложно ориентироваться
если будете писать на чистом ооп, то за пару сотен, большинство из которых отступы, лучше не переваливать)
12:55 Так неправильно переписан пример :) В первом варианте у тебя метод всегда возвращает строку, а во втором может быть как строка, так и void. Если бы соблюдалась строгая типизация, ты бы тут же словил эксепшн.
В остальном, всё гуд, новичкам будет полезно взять на заметку.
Почему бизнес логика в сервисах а не в сущностях?
Крутое видео. Полезная инфа. Хотелось бы услышать от Вас примеры применения шаблонов проектирования из реальной жизни (без котиков и собачек). Выучил большинство шаблонов, вроде все понял, а при решении задач трудно начать внедрять их. P.S. Очки лишние.
Благодарю. Многие паттерны уже реализованы на уровне фреймворков и библиотек, но в верхне-уровнем коде тоже приходится применять. Материалов на данную тему в сети достаточно много, посмотрю на досуге, может какие-то темы еще не освещены. Спасибо!
Неплохо, спасибо. Говнокоду бой !!!
Все хорошо, но не люблю когда демонстрируют примеры и говорят "ну так делать не нужно", а зачем ты это тогда показываешь? Показывайте на нормальных, реальных примерах, пусть будет сложнее, дольше, но за то реально чему то научит.
Беда в том, что так пишут люди которые не знают как правильно. К сожалению это не выдуманные примеры, это то с чем приходиться сталкиваться при ревью кода коллег. Вы всегда можете создать свой блог и выложить свой вариант примеров, которые вам кажутся более правильными.
Есть нормальное слово: "говнокод". Вот тут какие-то запахи ... Прям слушать тяжело.
Говнокод! Вот