Существуют ли какие-либо шаблоны проектирования, которые не нужны в динамических языках, таких как Python?

Я начал читать книгу шаблонов дизайна от GoF. Некоторые модели кажутся очень похожими с незначительными концептуальными различиями.

Считаете ли вы, что из многих шаблонов некоторые не нужны в динамическом языке, таком как Python (например, потому что они заменены динамическим признаком)?

Питер Норвиг показывает, что 16 из 23 шаблонов проектирования, описанных в книге GOF, невидимы или проще в динамических языках (он фокусируется на Лиспе и Дилане).

Поскольку вы упомянули Python, у Алекса Мартелли есть хорошая презентация на эту тему. Также, в связи с Python, есть хороший пост в блоге, демонстрирующий шесть шаблонов дизайна в идиоматическом Python .

Я также держу github-репозиторий с реализациями (другими людьми) наиболее распространенных шаблонов проектирования в Python .

Никаких шаблонов проектирования не требуется. На любом языке.

Я склонен сталкиваться с большим количеством кода, написанного людьми, которые читают шаблоны проектирования, а затем думают, что им следует использовать их повсеместно. В результате фактический код скрывается под тоннами интерфейсов, оболочек и слоев, и его довольно сложно прочитать. Это неправильный подход к шаблонам проектирования.

Шаблоны проектирования существуют для того, чтобы у вас был набор полезных идиом, пригодных для решения проблем. Но вы никогда не должны применять какой-либо шаблон, прежде чем выявить проблему. Keep It Simple Stupid всегда должен быть главным руководящим принципом.

Это также помогает думать о шаблонах проектирования как о концепции, позволяющей думать о проблеме, а не о конкретном шаблонном коде, который нужно написать. И о большей части стандартного обходного пути в качестве обходного пути к Java не хватает свободных функций и стандартных функциональных объектов, которые вы используете в большинстве других языков, в которых они есть (например, Python, C #, C ++ и т. Д.).

Я мог бы сказать, что у меня есть шаблон посетителя, но на любом языке с функциями первого класса это будет просто функция, принимающая функцию. Вместо фабричного класса у меня обычно есть только фабричная функция. Я мог бы сказать, что у меня есть интерфейс, но тогда это всего лишь пара методов, помеченных комментариями, потому что не было бы никакой другой реализации (конечно, в python интерфейс всегда является просто комментариями, потому что он имеет утку). Я до сих пор говорю о коде как об использовании шаблона, потому что это полезный способ думать об этом, но на самом деле не набирайте весь материал, пока он мне действительно не понадобится.

Итак, изучите все шаблоны как концепции . И забудьте о конкретных реализациях. Реализация меняется и должна меняться в реальном мире, даже в Java.

Абстрактный фабричный шаблон не нужен в языке утки, таком как Python, так как он практически встроен в язык.

Единственное, что приходит на ум - это модель Синглтона.

Поскольку Python не заставляет вас использовать классы для всего , вместо этого вы можете просто использовать глобальную структуру данных. Эта глобальная структура данных может управляться экземпляром, но вам не нужно управлять созданием этого класса, вы просто создаете экземпляр при импорте и оставляете все как есть.

В основном синглтоны в python заменены модулем. Модули в python по своей природе являются синглетонами; интерпретатор Python создает их только один раз.

Все другие шаблоны в Design Patters я использовал в Python то или иное время, и вы найдете их примеры во всей стандартной библиотеке Python и в самом Python.

Шаблоны проектирования предназначены для программиста, а не для языка. Программисты склонны использовать шаблоны, которые помогают им разобраться в проблеме. Никакой шаблон дизайна не является строго необходимым, но он может быть полезен, чтобы упростить то, что вы пытаетесь сделать.

Python, и, в частности, типизация утиным шрифтом, обеспечивает конец многим распространенным шаблонам и практикам, и многие ограничения, накладываемые некоторыми шаблонами (конфиденциальность, неизменность и т. Д.), Сохраняются только в той степени, в которой программист соглашается не нарушать их. , Но все - таки, они действительно работают до тех пор , как программист подыгрывает. Дверь остается дверью, даже если она обрамлена воображаемыми стенами.

Python считается «мультипарадигмальным» языком; Вы можете использовать любые шаблоны, которые вы хотите. Это намеренно. Например, он предусматривает сложные иерархии классов, даже если они совершенно не нужны и немного искусственны. Но для некоторых людей эта конкретная абстракция полезна. Не потому, что проблема требует этого, а потому, что программист делает. Итак, поехали.

Оригинальная книга «Шаблоны проектирования» документирована и названа некоторыми общими идиомами, полезными в императивных объектно-ориентированных языках, таких как C ++ и Smalltalk. Но Smalltalk - это язык с динамической типизацией, поэтому он не может быть просто вопросом динамичности.

Тем не менее, ответ на ваш вопрос по-прежнему «да»: некоторые из этих шаблонов проектирования не будут иметь отношения к современным динамически типизированным языкам. В более общем плане , будут различными шаблоны проектирования на разных языках, особенно в различных видах языков.

Повторим еще раз: «шаблон проектирования» - это просто название идиомы программирования: общее решение часто встречающейся проблемы. Разные языки требуют разных идиом, потому что проблема для одного языка может быть тривиальной для другого. В этом смысле шаблоны проектирования, как правило, указывают на слабые места в языках, к которым они применяются.

Таким образом, вы можете искать другие функции, которые делают современные динамические языки (или древние, такие как Lisp) более мощными, что делает некоторые из этих классических шаблонов проектирования неактуальными.

Шаблоны проектирования - это способы решения конкретных проблем. Если проблема не встречается, шаблон ее решения не имеет смысла.

Люди пытаются адаптировать шаблоны проектирования везде, как если бы это было наилучшей практикой - использовать шаблоны проектирования в вашем проекте. Это наоборот. Вы сталкиваетесь с проблемой, которую можно решить с помощью заводской схемы? Здорово. Адаптируй это. Не ищите свой код и не пытайтесь найти подходящее место для реализации синглтона (или фабрики, или фасада, или чего-то еще ...).

Возможно, у Python есть свои собственные шаблоны проектирования, недоступные для людей на Java и .NET (из-за природы этих языков)?

Я бы сказал, что шаблоны всегда зависят от языка. Большинство шаблонов python выглядят так же, как те, которые определены в GoF, потому что ООП Python говорит о том, что ООП не похож на ООП (никакие два языка не определяют объекты и их манипуляции на 100% одинаковые).

Поэтому нет сомнений, что некоторые шаблоны не будут применимы «как есть», некоторые могут не иметь смысла, и есть некоторые шаблоны, которые могут иметь смысл только для Python.

Чтобы точно ответить на ваш вопрос: шаблоны необходимы только в том случае, если они вам нужны . Вам не нужно их использовать, если в них нет необходимости (как уже сказал Ян Худек).

Кроме того, шаблонов гораздо больше, чем в GoF. Смотрите в википедии другие шаблоны