Насчёт префиксов для обозначения интерфейсов. Проблема в том, что само существование такого интерфейса выглядит искусственным. То есть он был создан, чтобы код удовлетворял каким-то принципам, или просто для юнит-тестирования. Вообще с интерфейсами возможны две ситуации: 1. Есть интерфейс и несколько возможных реализаций. В таком случае стоит интерфейс назвать естественным именем, а в именах реализаций использовать префиксы, которые опишут эту реализацию. Например, interface Author {} class LocalAuthor implements Author {} class ForeignAuthor implements Author {} 2. Есть интерфейс и одна реализация. Если другую реализацию сложно представить, то в таком случае интерфейс не нужен. Можно использовать класс с естественным именем. Да и в общем, если нет прямой необходимости использовать интерфейсы в проекте, то использование классов в механизме внедрения зависимостей вполне нормальная практика. Исключение - публичные библиотеки или пакеты. Все зависимости в них должны быть на интерфейсы (или абстрактные классы).
Огромное спасибо за разъяснение! Я в общем и целом совершенно согласен. Случай 2 мы, конечно, вообще не рассматриваем. Плодить интерфейсы "чтоб были" - не наш путь. С публичными библиотеками тоже понятно. А что касается инжекта - иногда я всё-таки хочу видеть, что сюда передано именно поведение. То есть, важен не столько объект и его класс со всеми возможными свойствами и поведением, сколько именно поведение, независимо от класса, его имплементирующего. В этом случае имя типа *_SomeInterface_* мне кажется довольно наглядным. Вот почему категоричность Мартина в этом вопросе меня слегка обескураживает. :) Ещё раз спасибо за подробный комментарий.
@@freelancer_eyes скорее всего смысл как раз таки в том, что нам должно быть не важно получили мы просто объект или объект, реализующий интерфейс. Коль метод требует интерфейс, то и работаем мы с ним согласно требуемому интерфейсу. Никаких проверок на тип внутри метода быть не должно. Вот и возникает вопрос, а зачем вам видеть, что это поведение, а не объект?
Классика, когда из мелочей вырастает огромный ком "неподдерживаемого" кода.. Близка мне Ваша философия, получить удовольствие от исправления чего то подобного) Благодарю за видео!
Спасибо за поддержку! Давайте с этой книгой разбёрёмся, там ещё 400 почти страниц осталось, гораздо более сложных. И если зрителям будет нравится - выберем вместе следующую книгу для разбора.
Прелестная подача, импонирует то, что Вы делитесь собственной мотивацией к прочтению книги с нами. В общем и целом, вероятнее всего отложил бы эту книгу в очередной раз подальше, но поскольку мне вот так формально через экран теперь есть с кем "поделиться" впечатлениями, читаю взахлёб. Жду продолжения, очень рад, что алгоритмы ютуба предложили мне Ваш канал.
"Repetitio est mater studiorum" - повторение - мать учения. Иногда полезно вспомнить основные моменты. Спасибо за видео и жду пролжения "чистого кода".
По поводу add и uppend тут еще один момент, в готовых решениях, если не ошибаюсь, чаще используется именно add. (например в коллекцию). И новому разработчику в команде оно может быть понятнее. Я в своем проекте использую uppend когда имеет значение добавляю именно в конец, и это важно с точки зрения бизнес -логики. И есть соответственно метод prepend
Про однобуквенные переменные, это тоже пережиток старых технологий. Когда экономили на спичках. Мол не используйте длинные переменные, можно сэкономить 1 секунду на генерации страницы в php). Я не говорю про минификации.
Обычно в моем случае PHP разработки заказчик просит сделать как можно быстрее MVP-версию продукта, а чистота кода ему не нужна. Про SOLID и паттерны вообще молчу. Но это наверно потому что заказчики относительно бедные.
В том-то и дело, что тяп-ляп MVP довольно сложно привести в чувство, если проект потребует развития. Но это случается не так часто, поэтому создается MVP просто как proof of concept, а потом он хоронится за ненадобностью. При таком подходе конечно не до SOLID: деньги на ветер
Про интерфейс тоже согласен. Но скорее всего он имеет в виду, что "а непонятно же, что ты передаешь". Например ModelInterface. User или Book? А может Session? А может пустую модель, некое наследие абстракции и все спокойно провалидируется конструктором. В его мыслях есть идея правильная, но на практике неприменима во МНОГИХ случаях. Я про передачу в конструктор, в вашем случае.
Retrive- извлечь из сторонних неких непонятных данных. Так именую. Причем retrive и get это разные вещи. После retrive обвертка гет над уже полученными данными. Extract когда данные в другом формате. Может я не прав
Как по мне, плохой пример сделали. $orderCount> AnyConstants::constant.. Должна быть абстракция $orderCount>GetMyVariavles::getAnyValue(AnyConstants::constant) . тому что сегодня из константы, а завтра база и опять же нужно менять. Но если честно, то >100 иногда тоже работает и тоже грешу)
Правильные имена переменных - это такие имена, которые несут в себе смысл того, что в них хранится. Всё! Как можно было тему "как назвать переменную" растянуть на 50 минут? Уму не постижимо. Причем тут трубочисты? Причем тут Ваше нынешнее рабочее место? Причем тут дома с разбитыми окнами? Что еще за "звучащий" код. Вода водяная. Бизнесу главное, чтобы задача была выполнена быстро и по ТЗ. Вообще плевать что там в коде. Если по пол часа размышлять о том как бы переменную получше назвать, то ни в какие дедлайны никогда не уложишься и будет не "проект с ужасным кодом", а просто - ничего не будет. Потому что такая долго выполняющаяся работа никому не нужна и проект просто развалится. Ну а если функция на пару сотен строк вызывает у кого-то ужас, то, скорее всего, этот человек и не программист вообще. В любой нормальной компании есть код-стайл и строгое ревью - там все неточности названий в переменных просто вынудят поправить Кому интересна тема - почитайте книгу и составьте свое личное мнение (на раздел с названиями переменных как раз 50 минут хватит). Остальным же не советую тратить время и рекомендую обойтись прочтением первой строки моего комментария
Ох не хотел бы я с такими, как вы, сталкиваться в работе. Автор несколько раз повторил, что не претендует на истину и что эта серия роликов не заменит книгу. Хотя я предположу, откуда у вас такая реакция. Слишком часто сталкивались с людьми, которые много говорят и мало делают, либо старпёрство высшего уровня. А ваша претензия по поводу 50 минут только на название переменной не имеет веса. В ролике рассказывается далеко не только про это. Тут самая настоящая каша из топора. P..S. Желаю как можно больше функций с сотнями строк кода, чтобы ваше самомнение не падало ;)
