Чи існують непотрібні шаблони дизайну в динамічних мовах, як Python?

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

Чи вважаєте ви, що з багатьох моделей деякі непотрібні в такій динамічній мові, як Python (наприклад, тому, що вони заміщені динамічною ознакою)?

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

Оскільки ви згадали про Python, є приємна презентація Алекса Мартеллі щодо цієї теми. Також пов'язаний з Python, є приємна публікація в блозі, де демонструються шість моделей дизайну в ідіоматичному Python .

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

Жодні шаблони дизайну не потрібні. На будь-якій мові.

Я, як правило, стикаюся з великою кількістю коду, написаного людьми, які читають про дизайнерські зразки, а потім думають, що їм слід їх використовувати всюди. Результат полягає в тому, що фактичний код закопується під тоннами інтерфейсів, обгортки та шарів і його досить важко читати. Це неправильний підхід до дизайнерських моделей.

Шаблони дизайну існують так, що вам потрібен репертуар корисних ідіом, коли ви стикаєтеся з проблемою. Але ніколи не слід застосовувати жодну схему, перш ніж визначити проблему. Зробити це просто Дурне завжди повинно бути вищим принципом управління.

Це також допомагає мислити дизайнерські шаблони як концепцію, щоб думати про проблему, а не про конкретний код котла для написання. І про більшу частину котлованної панелі, як для вирішення Java, яка не має вільних функцій та стандартних функціональних об'єктів, якими ви користуєтесь у більшості інших мов, на яких вони є (наприклад, Python, C #, C ++ тощо).

Я можу сказати, що у мене є шаблон відвідувачів, але будь-якою мовою з функціями першого класу це буде лише функція, яка приймає функцію. Замість заводського класу у мене зазвичай є лише фабрична функція. Я можу сказати, що у мене є інтерфейс, але тоді це лише пара методів, позначених коментарями, оскільки не було б жодної іншої реалізації (звичайно, в python інтерфейс завжди є лише коментарями, оскільки він набрав качку). Я все ще кажу про код як про використання шаблону, тому що це корисний спосіб продумати його, але насправді не вводити всі речі, поки мені це дійсно не потрібно.

Тож вивчіть усі закономірності як поняття . І забудьте конкретні реалізації. Реалізація різниться і повинна відрізнятися в реальному світі, навіть лише на Java.

Абстрактний заводський візерунок непотрібний у мові типу качки, як-от Python, оскільки він практично вбудований у мову.

Єдине, що спадає на думку, - це шаблон Singleton.

Оскільки Python не змушує вас використовувати класи для всього , ви можете просто використовувати глобальну структуру даних. Цією глобальною структурою даних може керувати примірник, але вам не потрібно контролювати інстанціювання цього класу, ви просто створите екземпляр при імпорті та залиште його при цьому.

Здебільшого, одиночні пітони замінюються модулем. Модулі в пітоні за своєю суттю є одиночними; інтерпретатор пітона створює їх один раз і лише один раз.

Всі інші зразки дизайну Patters я використовував у Python в той чи інший час, і ви знайдете приклади їх у всій стандартній бібліотеці Python та в самому Python.

Шаблони дизайну призначені для програміста, а не для мови. Програмісти, як правило, використовують моделі, які допомагають їм зрозуміти проблему. Жодна модель дизайну не є строго необхідною, але вона може бути корисною для спрощення того, що ви намагаєтеся зробити.

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

Python вважається мовою «багато парадигми»; Ви можете використовувати будь-які шаблони, які Ви хочете. Це навмисно. Наприклад, він передбачає складні ієрархії класів, хоча вони абсолютно непотрібні і трохи штучні. Але для деяких людей саме ця абстракція корисна. Не тому, що проблема цього вимагає, а тому, що це робить програміст. Так що ви йдете.

Оригінальна книга "Шаблони дизайну" задокументувала та назвала деякі загальні ідіоми, корисні в імперативних, об'єктно-орієнтованих мовах, таких як C ++ та Smalltalk. Але Smalltalk - мова, що динамічно набирається, тому не може бути суто питанням бути динамічним.

Однак відповідь на ваше запитання все ще «так»: деякі з цих моделей дизайну будуть неактуальними для сучасних динамічно набраних мов. У більш загальному плані , будуть різними шаблони проектування на різних мовах, особливо в різних видах мов.

Ще раз повторюю: "модель дизайну" - це просто назва ідіоми програмування: поширене рішення часто зустрічається проблеми. Для різних мов потрібні різні ідіоми, адже те, що є проблемою для однієї мови, може бути тривіальним для іншої. У цьому сенсі моделі дизайну, як правило, вказують на слабкі сторони мов, до яких вони застосовуються.

Отже, ви можете шукати інші функції, які роблять сучасні динамічні мови (або стародавні, такі як Lisp) більш потужними, а деякі з цих класичних моделей дизайну не мають значення.

Шаблони дизайну - це способи вирішення конкретних проблем. Якщо проблема не вирішена, схема її вирішення не має жодної користі.

Люди намагаються адаптувати шаблони дизайну скрізь так, як ніби найкраща практика мати у своєму проекті шаблони дизайну. Це навпаки. Ви стикаєтесь з проблемою, яку можна вирішити за допомогою заводського зразка? Класно. Адаптуйте його. Не шукайте свій код і не намагайтеся знайти потрібне місце для реалізації синглтона (або фабрики, або фасаду, або будь-якого іншого ...).

Можливо, Python має власні шаблони дизайну, недоступні для людей Java та .NET (через характер цих мов)?

Я б сказав, що закономірності завжди залежать від мови. Саме більшість шаблонів python виглядають як ті, що визначені в GoF, це через OOP Python, що, як кажуть, OOP не схожий на OOP (жодна дві мови не визначають об'єкти та їх маніпулювання на 100% однаково).

Тому немає сумнівів, що деякі зразки не застосовуватимуться "як є", а деякі можуть не мати сенсу, і є деякі зразки, які можуть мати значення лише для Python.

Щоб точно повернутися до вашого запитання: Візерунки потрібні лише в тому випадку, якщо вони вам потрібні . Не потрібно їх використовувати, якщо в них немає потреби (як уже сказав Ян Худець).

Крім того, існує набагато більше моделей, ніж зазначені у Міністерстві фінансів. Дивіться у вікіпедії інші зразки