Pattern di progettazione non OOP? [chiuso]

70

Ho sentito solo il termine "modello di progettazione" utilizzato per codice orientato agli oggetti e i modelli GoF includono solo modelli di progettazione OOP, ma i modelli di progettazione sono soluzioni eleganti per problemi di programmazione che si verificano comunemente, giusto? Non c'è nulla che affermi che devono essere limitati a OOP, vero?

Vorrei vedere alcuni esempi di modelli di progettazione al di fuori del regno della programmazione orientata agli oggetti. Hai qualche? Esistono addirittura (nessun libro, come il libro GoF, deve necessariamente essere stato scritto, dovrebbero essere semplicemente usati; è abbastanza)?

Possono essere specifici per alcuni linguaggi di programmazione, ma sono preferiti schemi generali (a livello di paradigma), di altri paradigmi rispetto a quello orientato agli oggetti.

design-patterns

— anto
fonte

8

Penso che il più grande disservizio che hanno fatto i libri sui modelli di design popolari sia stato quello di creare un sacco di persone che credevano che i modelli si applicassero solo a linguaggi orientati agli oggetti. I modelli di creazione sono discutibili, ma praticamente tutti gli altri possono e sono implementati in nessun linguaggio orientato agli oggetti per tutto il tempo. Sono sicuro che questo effetto collaterale non era l'intenzione dell'autore, ma comunque un effetto collaterale.

— Pemdas,

14

Bene, gli oggetti sono un modello di progettazione in lingue non OO :)

— back2dos

1

peggio ancora, i libri di schemi hanno creato un'intera classe di persone che credono che ogni problema dovrebbe essere risolto applicando uno schema specifico (di solito l'ultimo è stato insegnato da un insegnante di scuola che lui stesso crede allo stesso modo).

— jwenting

25

Dai un'occhiata alla serie Linux Kernel Design Patterns. Gli articoli sono correlati con un linguaggio non orientato agli oggetti (C) e credo che siano ben scritti:

— sakisk
fonte

Stanno usando un approccio orientato agli oggetti.

— Kais,

12

In realtà è un paradosso - uno dei modelli non OO più popolari è ... "Classe".

Poiché OO è stato inventato in linguaggi non OO, gli sviluppatori hanno dovuto simularlo (e lo stanno facendo anche adesso) - quindi il modello è nato. LISP e C ne sono esempi.

Ma segui il mio consiglio: non commettere errori comuni: non usare i pattern solo perché è bello , hai bisogno di serie ragioni per giustificare l'uso dei pattern (almeno quelli OO).

Prendi ad esempio il modello di comando - sebbene sia bello e disaccoppia il chiamante dal ricevitore, non dovrebbe essere usato a meno che tu non ne abbia effettivamente bisogno - perché le operazioni dovrebbero essere espresse usando i verbi - il che significa metodi. E usando i comandi in tutti i posti in cui ti ritroveresti con un mucchio di OO-lambda completamente decentralizzati -> lo stesso sarebbe vero per molte strategie.

— Kamil Tomšík
fonte

11

"Design pattern" è in realtà un eufemismo per "soluzione alternativa". I modelli di progettazione sono stati inventati per aggirare carenze e difetti nelle lingue OO . Ad esempio, prendi il modello iteratore che alla fine portò all'introduzione delle raccolte in Java. Groovy si è sbarazzato di molti altri motivi convertendoli in funzionalità del linguaggio: non è più necessario il motivo decorativo perché è possibile aggiungere metodi alle classi esistenti in Groovy.

Ciò significa che puoi trovare modelli di design ovunque. In effetti, ogni "migliore pratica" può essere considerata una forma semplice di un modello di progettazione.

— Aaron Digulla
fonte

9

Concordato! Da Paul Graham : "Ad esempio, nel mondo di OO si sente molto parlare di" schemi ". [...] Quando vedo schemi nei miei programmi, lo considero un segnale di difficoltà. La forma di un programma dovrebbe riflettere solo il problema che deve risolvere. Qualsiasi altra regolarità nel codice è un segno, almeno per me, che sto usando astrazioni che non sono abbastanza potenti - spesso che sto generando a mano le espansioni di alcune macro che ho bisogno di scrivere ".

— Andres F.

7

Non sono d'accordo con un modello di progettazione che sia una soluzione alternativa. I due sono opposti. Una soluzione alternativa è una patch a breve termine messa insieme per bypassare un ostacolo specifico. I modelli di progettazione sono soluzioni riutilizzabili a lungo termine. Lo scopo del motivo decoratore è quello di aggiungere funzionalmente 'senza' modificare la classe. Puoi mettere diversi decoratori su un oggetto senza che l'oggetto lo sappia.

— Despertar,

Il motivo per cui i motivi sono considerati una "soluzione alternativa" è perché decorare un oggetto dovrebbe essere una caratteristica del linguaggio. Invece, dobbiamo scrivere molte, molte righe di codice per implementare questo. Ad esempio, il modello iteratore è diventato parte di molti linguaggi moderni. Per le lingue OO più vecchie, è necessario saltare un paio di cerchi per simularle.

— Aaron Digulla,

@AaronDigulla Non vedo perché pensi che uno schema come il decoratore sia un'implementazione così pesante; stai parlando di alcune righe di codice. Una classe contiene un'altra classe e inoltra le richieste con alcune funzionalità aggiunte. Usa l'ereditarietà e la composizione in un modo che rende la chiamata di un oggetto decorato equivalente alla chiamata dell'oggetto stesso. Ritengo che questa trasparenza sia un punto di forza. Ciò ti consente di sostituire i decoratori in fase di esecuzione. Quando dici che groovy non ha bisogno di decoratore perché può aggiungere metodi a una classe sembra che ti stia perdendo il punto.

— Despertar,

2

Il modello Iterator non è stato sostituito da nessuna nuova funzionalità linguistica nelle lingue moderne. Viene fornito con un'implementazione predefinita per le raccolte comuni. Solo perché ha un'implementazione predefinita non significa che il modello non venga utilizzato. Se scrivi la tua collezione, dovresti implementarla da solo.

— Despertar,

10

LtU afferma che Jeremy Gibbons sta scrivendo un libro sugli schemi nella programmazione funzionale. Dai un'occhiata al blog di Mr. Gibbon's Patterns in Functional Programming per alcuni teaser. Nota che raccomanda di leggere i suoi post dal più vecchio al più recente.

Il suo paper Design Patterns come programmi generici di datatype di ordine superiore (pdf) modella funzionalmente la banda di quattro pattern: composito, Iterator, Visitor e Builder. Descrive i modelli di programmazione con equazioni ricorsive nella Programmazione Origami (pieghe e spiegazioni).

— Corbin March
fonte

9

Esistono modelli di progettazione SQL .

E esistono anche alcuni modelli di design funzionale - vedi qui per scala.

— Oded
fonte

Lo scala link è rotto

— corvus_192

7

Invece di nominare modelli di design diversi da quelli di oo vorrei darti alcuni esempi di libri che hanno molti modelli di design (in essi alcuni modelli saranno ancora specifici di OO):

Guarda i libri POSA per esempi di architettura software
- Calcolo distribuito
- Pattern per oggetti concorrenti e in rete
- Modelli per la gestione delle risorse
Modelli di Fowlers di architettura aziendale con catalogo online
xUnit Test pattern con sito Web
E naturalmente dove sono nati i modelli: il modo senza tempo di costruire di Christopher Alexander

Spero che sia di aiuto

— KeesDijk
fonte

Questi sono quelli che consiglierei anche, oltre a Hohpe & Woolf's Enterprise Integration Patterns .

— TMN,

I modelli di Fowler sono altamente OO :)

— David Conde,

@David Conde :) Molti di essi sono OO puri, tutti sono scritti in modo OO, ma alcuni di essi si applicano anche a non OO: guarda "Modelli di presentazione Web", "Modelli di stato della sessione", "Modelli di distribuzione "

— KeesDijk,

2

Nella programmazione funzionale (specialmente Haskell), ci sono molti schemi e modi di dire che non si associano molto bene a OOP. I tipi fantasma sono un esempio ben noto e puoi trovare molto di più nella pagina wiki di haskell su Idioms .

— yatima2975
fonte

1

La programmazione modulare è piuttosto popolare per le biblioteche numeriche e le applicazioni matematiche pesanti (il software numerico è notoriamente difficile da modellare usando i modelli orientati agli oggetti, soprattutto perché c'è molto poco che puoi incapsulare).

— quant_dev
fonte

Utilizzato in JS e "pure C": en.wikipedia.org/wiki/Module_pattern

— umlcat

1

Un buon esempio di pattern non OOP è il mio catalogo di pattern preferito in assoluto: Pattern organizzativi di sviluppo software agile, di James O. Coplien . Questo libro non tratta i modelli di software, riguarda le persone, un catalogo per creare team di successo. Ogni manager dovrebbe leggere questo libro!

— JuanZe
fonte

0

Mi piace pensare a Data Strucutres come code, elenchi collegati, alberi, grafici, ecc. Come schemi. Definiscono determinati modelli per archiviare i dati e elaborarli. Possono sembrare primitivi rispetto agli schemi più di fascia alta di Gang of Four, ma sono comunque modelli. Voglio dire, cosa accadrebbe se qualcuno implementasse uno stack come FIFO anziché come LIFO e viceversa per una coda e li nominasse altrimenti?

— DPD
fonte