И
Size: a a a
2020 January 04
И
Вот его вебинар
И
Очень крутой по декораторам аля джава вэй
VK
Вставлю свои пять копеек)
Мне кажется, что эти паттерны полезны для любого программиста) И большинство можно реализовать на js, а если нельзя на js - точно на ts можно) Это же лучшие практики, выработанные и проверенные годами) не очень правильно думать, что js в этом плане дает возможность обо всем этом забыть) Это скорее его недостаток, с которым кстати активно воюют (тот же тс, фреймворки типа nest). По-моему, знаешь паттерны, а именно ПОНИМАЕШЬ ЗАЧЕМ ОНИ - пишешь код лучше)
Мне кажется, что эти паттерны полезны для любого программиста) И большинство можно реализовать на js, а если нельзя на js - точно на ts можно) Это же лучшие практики, выработанные и проверенные годами) не очень правильно думать, что js в этом плане дает возможность обо всем этом забыть) Это скорее его недостаток, с которым кстати активно воюют (тот же тс, фреймворки типа nest). По-моему, знаешь паттерны, а именно ПОНИМАЕШЬ ЗАЧЕМ ОНИ - пишешь код лучше)
IL
Singleton и Builder
остальные не помню
остальные не помню
На самом деле можно и без них обходиться.
Излишнее усложнение.
Это больше зависит уже от в принципе взглядов команды и подходов
Я конечно больше за ООП подход, я везде беру ТС, но в чистом жс лучше не надо
Излишнее усложнение.
Это больше зависит уже от в принципе взглядов команды и подходов
Я конечно больше за ООП подход, я везде беру ТС, но в чистом жс лучше не надо
AK
паттерны знать нужно, но начинать учить их только тогда, когда сам почувствуешь что нужно иначе проку не будет
s🐱
Вставлю свои пять копеек)
Мне кажется, что эти паттерны полезны для любого программиста) И большинство можно реализовать на js, а если нельзя на js - точно на ts можно) Это же лучшие практики, выработанные и проверенные годами) не очень правильно думать, что js в этом плане дает возможность обо всем этом забыть) Это скорее его недостаток, с которым кстати активно воюют (тот же тс, фреймворки типа nest). По-моему, знаешь паттерны, а именно ПОНИМАЕШЬ ЗАЧЕМ ОНИ - пишешь код лучше)
Мне кажется, что эти паттерны полезны для любого программиста) И большинство можно реализовать на js, а если нельзя на js - точно на ts можно) Это же лучшие практики, выработанные и проверенные годами) не очень правильно думать, что js в этом плане дает возможность обо всем этом забыть) Это скорее его недостаток, с которым кстати активно воюют (тот же тс, фреймворки типа nest). По-моему, знаешь паттерны, а именно ПОНИМАЕШЬ ЗАЧЕМ ОНИ - пишешь код лучше)
Кстати умные ребята сейчас довольно часто отказываются от паттернов (в сторону фп, кто бы сомневался) и продавливают идею что ООП экспоненциально плодит количество классов которые нужно поддерживать. У этой медали есть две стороны, но быть знакомым с паттернами не помешает
VK
На самом деле можно и без них обходиться.
Излишнее усложнение.
Это больше зависит уже от в принципе взглядов команды и подходов
Я конечно больше за ООП подход, я везде беру ТС, но в чистом жс лучше не надо
Излишнее усложнение.
Это больше зависит уже от в принципе взглядов команды и подходов
Я конечно больше за ООП подход, я везде беру ТС, но в чистом жс лучше не надо
Где-то слышал фразу, что сложность побеждается сложностью) Понятно, что паттерны проектирования покажут свою пользу только в долгоиграющем сложном (комплексном) проекте, который надо расширять и поддерживать)
AS
На самом деле можно и без них обходиться.
Излишнее усложнение.
Это больше зависит уже от в принципе взглядов команды и подходов
Я конечно больше за ООП подход, я везде беру ТС, но в чистом жс лучше не надо
Излишнее усложнение.
Это больше зависит уже от в принципе взглядов команды и подходов
Я конечно больше за ООП подход, я везде беру ТС, но в чистом жс лучше не надо
спасибо за ответы учту
IL
спасибо за ответы учту
Если взять, допустим, обсервер..
Он в принципе не очень нужен так как js кроме всего это событийно ориентированный язык и все вращается вокруг событий (чего уж, в ядре всего то ивент луп).
Важно понимать как он работает и почему нужно всегда использовать асинхронность и как ею управлять.
Взять тот же DI, его невозможно реализовать в каноническом виде в чистом жс и даже в тс из-за того что интервейсов в принципе не существует в рантайме, даже рефлексия это эдакой муляж.
Потому DI тоже неполноценный и в большинстве случаев он может только навредить, а не дать преимущества.
И тут лучше уж вникать в конкретную реализацию .. например, inversify.
Но очень осторожно
В ангуляре/NestJS весьма интересная реализация тоже.
Он в принципе не очень нужен так как js кроме всего это событийно ориентированный язык и все вращается вокруг событий (чего уж, в ядре всего то ивент луп).
Важно понимать как он работает и почему нужно всегда использовать асинхронность и как ею управлять.
Взять тот же DI, его невозможно реализовать в каноническом виде в чистом жс и даже в тс из-за того что интервейсов в принципе не существует в рантайме, даже рефлексия это эдакой муляж.
Потому DI тоже неполноценный и в большинстве случаев он может только навредить, а не дать преимущества.
И тут лучше уж вникать в конкретную реализацию .. например, inversify.
Но очень осторожно
В ангуляре/NestJS весьма интересная реализация тоже.
VK
Кстати умные ребята сейчас довольно часто отказываются от паттернов (в сторону фп, кто бы сомневался) и продавливают идею что ООП экспоненциально плодит количество классов которые нужно поддерживать. У этой медали есть две стороны, но быть знакомым с паттернами не помешает
Если следовать open/closed принципу, то для добавления новых фич нужно добавлять новый код и по минимуму править старый)
Но это действительно в полной мере оправданно в больших проектах со сложной бизнес логикой)
Но это действительно в полной мере оправданно в больших проектах со сложной бизнес логикой)
И
Если взять, допустим, обсервер..
Он в принципе не очень нужен так как js кроме всего это событийно ориентированный язык и все вращается вокруг событий (чего уж, в ядре всего то ивент луп).
Важно понимать как он работает и почему нужно всегда использовать асинхронность и как ею управлять.
Взять тот же DI, его невозможно реализовать в каноническом виде в чистом жс и даже в тс из-за того что интервейсов в принципе не существует в рантайме, даже рефлексия это эдакой муляж.
Потому DI тоже неполноценный и в большинстве случаев он может только навредить, а не дать преимущества.
И тут лучше уж вникать в конкретную реализацию .. например, inversify.
Но очень осторожно
В ангуляре/NestJS весьма интересная реализация тоже.
Он в принципе не очень нужен так как js кроме всего это событийно ориентированный язык и все вращается вокруг событий (чего уж, в ядре всего то ивент луп).
Важно понимать как он работает и почему нужно всегда использовать асинхронность и как ею управлять.
Взять тот же DI, его невозможно реализовать в каноническом виде в чистом жс и даже в тс из-за того что интервейсов в принципе не существует в рантайме, даже рефлексия это эдакой муляж.
Потому DI тоже неполноценный и в большинстве случаев он может только навредить, а не дать преимущества.
И тут лучше уж вникать в конкретную реализацию .. например, inversify.
Но очень осторожно
В ангуляре/NestJS весьма интересная реализация тоже.
В ангуляре есть injection token
AS
Если следовать open/closed принципу, то для добавления новых фич нужно добавлять новый код и по минимуму править старый)
Но это действительно в полной мере оправданно в больших проектах со сложной бизнес логикой)
Но это действительно в полной мере оправданно в больших проектах со сложной бизнес логикой)
я так понял там как раз нужны джуны на легаси на експрессе
s🐱
Если следовать open/closed принципу, то для добавления новых фич нужно добавлять новый код и по минимуму править старый)
Но это действительно в полной мере оправданно в больших проектах со сложной бизнес логикой)
Но это действительно в полной мере оправданно в больших проектах со сложной бизнес логикой)
Solid в проектах работает еще реже, чем паттерны)
И
Который роль интерфейса для di
И
Выполняет
s🐱
Solid в проектах работает еще реже, чем паттерны)
Как и grasp, в общем то
И
Костыльно но както работает
VK
Плюс паттерны позволяют разработчикам говорить на одном языке плюс/минус) А не "у нас так принято")
И
В тестах можно подменять зависимости