Esistono schemi di progettazione non necessari in linguaggi dinamici come Python?

Peter Norvig dimostra che 16 dei 23 modelli di progettazione trovati nel libro GOF sono invisibili o più semplici in linguaggi dinamici (si concentra su Lisp e Dylan).

Da quando hai citato Python, c'è una bella presentazione di Alex Martelli sull'argomento. Legato anche con Python, c'è un bel post sul blog che dimostra sei pattern di design in Python idiomatico .

Conservo anche un repository github con implementazioni (di altre persone) dei schemi di progettazione più comuni in Python .

Non sono necessari modelli di progettazione. In qualsiasi lingua.

Tendo a leggere un sacco di codice scritto da persone che leggono schemi di progettazione e poi pensano che dovrebbero usarli ovunque. Il risultato è che il codice reale viene sepolto sotto tonnellate di interfacce, wrapper e layer ed è piuttosto difficile da leggere. È un approccio sbagliato nei modelli di progettazione.

Esistono schemi di progettazione in modo da avere a portata di mano un repertorio di utili idiomi quando si incontra un problema. Ma non dovresti mai applicare alcun modello prima di identificare il problema. Keep it Simple Stupid dovrebbe sempre essere il principio di governo superiore.

Aiuta anche a pensare a schemi di progettazione come a un concetto per pensare al problema piuttosto che a un codice specifico da scrivere. E su gran parte del boilerplate come soluzione alternativa a Java priva di funzioni gratuite e oggetti funzione standard che usi nella maggior parte degli altri linguaggi che li hanno (come Python, C #, C ++, ecc.)

Potrei dire che ho uno schema di visitatore, ma in qualsiasi lingua con funzioni di prima classe sarà solo una funzione che prende una funzione. Invece della classe di fabbrica, solitamente ho solo una funzione di fabbrica. Potrei dire che ho un'interfaccia, ma sono solo un paio di metodi contrassegnati con commenti, perché non ci sarebbero altre implementazioni (ovviamente in python un'interfaccia è sempre solo commenti, perché è tipizzata a forma di anatra). Parlo ancora del codice come se usassi il pattern, perché è un modo utile per pensarci, ma in realtà non digito tutte le cose finché non ne ho davvero bisogno.

Quindi impara tutti i pattern come concetti . E dimentica le implementazioni specifiche. L'implementazione varia e dovrebbe variare nel mondo reale, anche solo in Java.

Modello di fabbrica astratto non è necessario in un linguaggio dattiloscritto come Python, poiché è praticamente costruito nella lingua

L'unico che viene in mente è il pattern Singleton.

Dato che Python non ti obbliga a usare le classi per tutto , puoi semplicemente utilizzare una struttura dati globale. Quella struttura di dati globale potrebbe essere gestita da un'istanza, ma non devi controllare l'istanza di quella classe, devi solo creare l'istanza all'importazione e lasciarla a quella.

Per lo più, i singleton in python sono sostituiti con un modulo. I moduli in python sono per loro natura singleton; l'interprete python crea questi una volta sola.

Tutti gli altri pattern in Design Patters che ho usato in Python in una volta o l'altra, e troverai esempi di questi in tutta la libreria standard di Python e in Python stesso.

I modelli di progettazione sono per il programmatore, non per la lingua. I programmatori tendono a utilizzare schemi che li aiutano a dare un senso al problema in questione. Nessun modello di progettazione è strettamente necessario, ma potrebbe essere utile per semplificare ciò che stai cercando di fare.

Python, e tipizzando anatra in modo specifico, fornisce una fine attorno a molti schemi e pratiche comuni, e molte delle restrizioni impostate da alcuni modelli (privacy, immutabilità, ecc.) sono valide solo nella misura in cui il programmatore non accetta per romperli. Tuttavia, fanno funzionano fintanto che il programmatore suona. Una porta è ancora una porta, anche se è incorniciata da muri immaginari.

Python è considerato un linguaggio "multi-paradigma"; puoi usare qualunque modello tu voglia. Questo è intenzionale. Fornisce gerarchie di classi complesse, ad esempio, anche se sono completamente inutili e un po 'artificiali. Ma per alcune persone questa particolare astrazione è utile. Non perché il problema lo richieda, ma perché lo fa il programmatore. Quindi eccoci.

Il libro originale "Design Patterns" è stato documentato e chiamato alcuni idiomi comuni utili in linguaggi imperativi orientati agli oggetti come C ++ e Smalltalk. Ma Smalltalk è un linguaggio tipizzato dinamicamente, quindi non può essere strettamente una questione di dinamicità.

Tuttavia, la risposta alla tua domanda è ancora "sì": alcuni di questi modelli di progettazione saranno irrilevanti per le lingue moderne dinamicamente tipizzate. Più in generale, ci saranno diversi modelli di design in diverse lingue, specialmente in diversi tipi di lingue.

Per ribadire: un "modello di progettazione" è semplicemente un nome per un linguaggio di programmazione: una soluzione comune a un problema incontrato di frequente. Lingue diverse richiedono idiomi diversi, perché quello che è un problema per una lingua può essere banale per un'altra. In questo senso, i modelli di progettazione tendono a evidenziare punti deboli nelle lingue a cui si applicano.

Quindi, potresti cercare altre funzionalità che rendano i moderni linguaggi dinamici (o quelli antichi come Lisp) più potenti, rendendo irrilevanti alcuni di questi modelli di design classici.

I modelli di progettazione sono modi per risolvere problemi particolari. Se un problema non viene soddisfatto, il modello di risoluzione non ha senso.

Le persone cercano di adattare i modelli di progettazione ovunque, come se fosse una buona pratica avere schemi di progettazione nel proprio progetto. Questo è l'altro modo. Incontri un problema che può essere risolto con un modello di fabbrica? Freddo. Adattalo. Non cercare il codice e cercare di trovare il posto giusto per implementare un singleton (o fabbrica, o facciata, o qualsiasi altra cosa ...).

Forse Python ha i propri modelli di progettazione non disponibili per le persone Java e .NET (a causa della natura di questi linguaggi)?

Direi che i pattern dipendono sempre dalla lingua. Il fatto che la maggior parte dei pattern Python assomiglino a quelli definiti in GoF è dovuto all'OOP di Python, il fatto che OOP non sia come OOP (non esistono due lingue che definiscono gli oggetti e la loro manipolazione allo stesso modo al 100%).

Quindi non c'è dubbio che alcuni pattern non saranno applicabili "così come sono", alcuni potrebbero non avere senso e ci sono alcuni pattern che potrebbero essere significativi solo per Python.

Per tornare esattamente alla tua domanda: i pattern sono necessari solo se hai bisogno di loro. Non devi usarli se non ce n'è bisogno (come diceva già Jan Hudec).

Inoltre, ci sono molti più schemi di quelli menzionati in GoF. Vedi in wikipedia altri modelli