вызова и внутри handle не пишем логику, а вызываем какой-то класс, который в свою очередь может быть сделан через другой паттерн, верно?
Если это оправданно и в этом есть необходимость
К примеру, есть разные вариации отправки письма, нужно ли их делать через абстрактную фабрику, а само поведение через цепочку (если одна отправка не удалась, пробуем следующую) ?
Паттерны имеют свойство возникать сами собой, в процессе написания кода. Ничего они не усложняют.
Люди начинаються гоф и что-то схожее и начинают везде где можно паттерны ебошить в коде, ну да паттерны ничего не усложняют =)
Ну сделать херово можно и так и эдак.
1. Паттерны можно комбинировать. 2. Паттерны достаточно условны, например ту же цепочку ответственности можно по всякому реализовать. Но смысла оно не потеряет. 3. Паттерны полезны как идеи, тебе надо разбираться какие проблемы какая идея призвана решить. 4. Как "обоснование" почему паттерны выходят такими есть книжка лармана applying uml and patterns где он вводит grasp - тип набор более общих идей соблюдение которых будет приводить к появлению паттернов гоф-ских
Спасибо
смотря что понимать под "усложняют", паттерны вносят дополнителные абстракции. Чем больше абстракций - тем сложнее понимать код
Добавлю, паттерны какбе нормально подходят в кейсах когда их можно наложить на реально то, что делает код по смыслу. Просто запихуное по книжечке это как сказали выше «сделать херово можно в любом случае» Тут челлендж смапить существующие паттерны на твой юзкейс без глупого оверинжиниринга.
формулировка "паттерны подходят не подходят" не верна в том плане что причинно следственные связи перепутаны. Не паттерны задают решения в коде а решения в коде задают паттерны. знать тебе их надо что бы удобнее объяснить кому-то че и как сделать. условно "захерачь там фабрику которая как чейн оф респонсидилити стратегию выбирает" бла бла. Не стоит фокусировать столько внимания на конкретном примере реализации того или иного паттерна - важно разобраться какую проблему оно решает и почему выглядит так как выглядит. Это то где надо думать да, и потому книжки на эту тему пишут. А не потому что "надо паттерны заучить и применить их все иначе не станешь мастером покемонов"
по паттернам книг действительно много, а есть ли литература по улучшению кода на более низком уровне? ну те. где предпочесть ранний return, где отказаться от for цикла в пользу while с установкой флагов и тд? самое близкое что читал это совершенный код
Это из разряда микрооптимизаций и зависит от конкретного языка и рантайма
ага, я бы с удовольствием почитал аналог совершенного кода под ts или хотя бы java/c#
Совершенный код как раз вроде и не прибит к языкам / рантаймам
Чистый код из той же темы - можно почитать. Ещё про фп можно
странно, про эту от чего-то не слышал, спасибо
Это дядя Боб, у него есть ещё чистая архитектура
её читал, да, возможно потому и пропустил, так как названия похожи
Для того чтобы понимать как писать код лучше, на низком уровне - рефакторинг и может быть чистый код/чистая архитектура, имхо совершенный код намного дальше от того как принимать решения. Причем я бы рекомендовал именно рефакторинг на java, а не издание на js если в переводе. И не сайт рефакторинг гуру, потому что он не про путь, а про результат.
А какая цель этих улучшений - оптимизации, или повышение читаемости? Если оптимизации, то тут надо глубоко погружаться в низкие уровни, вплоть до изучения механизмов сброса/наполнения кешей. Не знаю даже есть ли такая литература А если улучшение читаемости кода, то советы уже дали
читаемость, я люблю глазами и то как выглядит и насколько читабелен код это важный аспект для меня
Фаулер рефакторинг
Обсуждают сегодня