ну, паттерны они же для чего нужно? они решают некоторые проблемы, есть проблема - они вот предлагают общий способ решить её, а реализация, да, реализаций много, по моей ссылке я бы сказал они реализованы на питоне в стиле Java-way

просто когда таких паттернов несколько и смотришь на них через полгода, это не секунду времени занимает, чтобы понять всё, а если ещё и скроллить...

портирование классической java-реализации в питон :)

мне иногда кажется, что использование паттернов создает большие проблемы, чем то ради чего их пытались применить

А если ещё и не применять их бездумно и именовать лучше, чем *Abstraction*, *Extension*, *Adapter*, etc

List... Tuple... хорошие имена для переменных )))

А, и еще Dict!

я иногда не понимаю, зачем фокусировать внимание на классах и объектах вместо того, чтобы думать про действия, ведь нам нужны именно они, а кто их делает? пусть будет СуперНепонятноеАбстрактноеНечто и ладно 😊 но я интересуюсь разными подходами, возможно, если они так популярны, там и правда есть что-то в этом)

Я видел огромное кол-во плохого кода, где его "паттернизация" превратила в кашу, которую знает 1-2 разраба. А также много хороших проекто, которые не заморачивались слишком слиьно с этим.
Да, разрабы знали эти паттерны, но нет они общались не ими, а бизнес-сущностями, поведение которых им нужно было воплотить в коде.

Вот честно, монолит где пакеты вида forms, models, views довольно сложно понять. А вот с пакетами по форме profile, auth, orders всё много проще.

собственно, вот тут проблема с реализацией, которая вместо упрощения усложняет код

потом там будет FormFactory, ModelFactory.... потом FormFactoryBuilder, ModelFactoryBuilder...

Потому что думать надо не паттернами техническими, а терминами предметной области)

тут выглядит как выбор: терпеть некую проблему или решить проблему, но усложнить понимание кода и не факт, что второе лучше первого

а есть ли проблема?

в идеале, конечно, если бы IDE подсказывала, что сделать

ну, паттерны - это же решение проблем, ответ на возникшие проблемы

nyet

то есть была какая-то проблема, думали-думали как её решить и появилась реализация, когда 100 человек сделали примерно то же самое, решили ту же проблему примерно тем же способом - сформировался паттерн и его стали раскручивать как способ решения проблемы

ну, понятно, что у 100 человек реализация будет отличаться, но суть будет той же самой, вот эта суть - и есть паттерн проектирования как способ решения проблемы

то есть понятно, что нет проблемы - и паттерны не нужны