Согласен с тезисом "нужно делать проще", это факт и оверинжиниринг ни у чему хорошему не приводит на дистанции. Но:
Синглтон - антипаттерн ужо много лет, строитель, в вашем примере, не то, о чем писали GoF.
Суть паттерна строитель не в классе с методами SetSomething, а в комбинации builder+director. Строитель у вас это врождённое нечто из мира ООП, которое в питоне, конечно ни к чему. Ну и логики обычно там поболе, параметрами по-умолчанию не отделаешься.
Как мне кажется в статье рассмотрены самые неверно понимаемые паттерны. Экстраполировать на все остальное я бы не стал.
В общем-то паттерны существуют для того, чтобы упрощать сложную логику. Если сложной логики в приложении нет - то и накручивать смысла нет.
Однако, стратегия, например, очень даже повсеместно используемый паттерн, без которого расширяемую реализацию писать ой как тяжело.
Я честно пытался натянуть на глобус эти "прогнозы", но все таки осталось стойкое ощущение, что как и все остальные гороскопы - этот только для тех, кто верит в такого рода "предсказания".
Со всем уважением к проделанной работе! Молодцы ребята, монетзируйте свой труд, идея в целом дорогого стоит.
Видимо, каждый стиль обучения под себя подстраивает. Я вот GoF не осилил, а те же паттерны от Head First зашли очень даже и заняли почетное место на полке.
Спасибо за статью! С одной стороны очевидные вещи по индексам, когда с этим часто работаешь, но практика показывает, что для многих факт отличия одного индекса по (А+Б) и двух по (А) и (Б) не очевиден.
А кто нибудь сталкивался с необходимостью применения шаблона Bulkhead?
По мне выглядит так, что это решается горизонтальным масштабированием сервиса и декомпозиции нагруженных компонентов в сервисе (отделение в самостоятельные сервисы, например)
Более тесная интеграция с сервисом привлечения (в примере автора есть триггер на страницу "Спасибо"). Достаточно отдать ему некий уникальный идентификатор пользователя при заказе и тот же Яндекс запомнит, что конкретно этот человек соотносится с таким идентификатором в этом конкретном магазине, ну а дальше все по кругу.
Обычно магазину это выгодно делать (техническая реализация окупается), поскольку иначе каждый заказ будет считаться "новым клиентом", а стоимость новых выше чем повторное привлечение.
Согласен с тезисом "нужно делать проще", это факт и оверинжиниринг ни у чему хорошему не приводит на дистанции. Но:
Синглтон - антипаттерн ужо много лет, строитель, в вашем примере, не то, о чем писали GoF.
Суть паттерна строитель не в классе с методами SetSomething, а в комбинации builder+director. Строитель у вас это врождённое нечто из мира ООП, которое в питоне, конечно ни к чему. Ну и логики обычно там поболе, параметрами по-умолчанию не отделаешься.
Как мне кажется в статье рассмотрены самые неверно понимаемые паттерны. Экстраполировать на все остальное я бы не стал.
В общем-то паттерны существуют для того, чтобы упрощать сложную логику. Если сложной логики в приложении нет - то и накручивать смысла нет.
Однако, стратегия, например, очень даже повсеместно используемый паттерн, без которого расширяемую реализацию писать ой как тяжело.
Выглядит здорово! Будем ждать релиз)
Довольно таки толстенько
Я честно пытался натянуть на глобус эти "прогнозы", но все таки осталось стойкое ощущение, что как и все остальные гороскопы - этот только для тех, кто верит в такого рода "предсказания".
Со всем уважением к проделанной работе! Молодцы ребята, монетзируйте свой труд, идея в целом дорогого стоит.
Покажите программисту Шамсудину Typescript, он будет в восторге!)
А вообще типизация конечно да...
P.s. имени программиста Шамсудина в статье нет. Неуважительно как-то что ли..
Нуу.. изменилось примерно все :)
Имеет смысл ещё раз присмотреться.
Видимо, каждый стиль обучения под себя подстраивает. Я вот GoF не осилил, а те же паттерны от Head First зашли очень даже и заняли почетное место на полке.
Спасибо за статью! С одной стороны очевидные вещи по индексам, когда с этим часто работаешь, но практика показывает, что для многих факт отличия одного индекса по (А+Б) и двух по (А) и (Б) не очевиден.
А кто нибудь сталкивался с необходимостью применения шаблона Bulkhead?
По мне выглядит так, что это решается горизонтальным масштабированием сервиса и декомпозиции нагруженных компонентов в сервисе (отделение в самостоятельные сервисы, например)
Кажется, что Bulkhead требует много поддержки.
Более тесная интеграция с сервисом привлечения (в примере автора есть триггер на страницу "Спасибо"). Достаточно отдать ему некий уникальный идентификатор пользователя при заказе и тот же Яндекс запомнит, что конкретно этот человек соотносится с таким идентификатором в этом конкретном магазине, ну а дальше все по кругу.
Обычно магазину это выгодно делать (техническая реализация окупается), поскольку иначе каждый заказ будет считаться "новым клиентом", а стоимость новых выше чем повторное привлечение.