Modelli di progettazione non OOP? [chiuso]

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

• Modelli di progettazione del kernel Linux - Parte 1
• Modelli di progettazione del kernel Linux - Parte 2
• Modelli di progettazione del kernel Linux - Parte 3
• Ghosts of Unix Past: una ricerca storica di modelli di design
• Ghosts of Unix past, part 2: Conflated designs
• Ghosts of Unix passato, parte 3: Disegni non risolvibili
• Ghosts of Unix passato, parte 4: Design ad alta manutenzione

In realtà è un paradosso: uno dei più popolari pattern Non-OO è ... "Class".

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

Ma segui il mio consiglio: Non commettere errori comuni - non utilizzare modelli solo perché è bello , hai bisogno di seri motivi per giustificare l'uso del modello (almeno quelli OO).

Ad esempio, prendi il comando Comando, anche se è bello & 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 tutto il posto in cui ti ritroverai con un gruppo di OO-lambdas completamente decentralizzati - > lo stesso sarebbe vero per un sacco di strategie.

"Design pattern" è in realtà un eufemismo per "soluzione". I modelli di design sono stati inventati per ovviare a carenze e difetti nelle lingue OO . Ad esempio, prendi il pattern iteratore che alla fine ha portato all'introduzione delle collezioni in Java. Groovy ha eliminato molti altri motivi convertendoli in funzioni linguistiche: non hai più bisogno del pattern di decoratore perché puoi aggiungere metodi a Groovy in classi esistenti.

Questo significa che puoi trovare schemi di design ovunque. In effetti ogni "buona pratica" può essere considerata una semplice forma di modello di progettazione.

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

Il suo articolo Progetta modelli come programmi generici di tipo datatype di ordine superiore (pdf) modella in modo funzionale i modelli Gang of Four: Composite, Iterator, Visitor e Builder. Descrive i modelli di programmazione con equazioni ricorsive in Programmazione Origami (si piega e si apre).

Ci sono modelli di progettazione SQL .

Esistono anche alcuni modelli di design funzionali - vedi qui per scala.

Invece di nominare modelli di progettazione non-oo, vorrei darti alcuni esempi di libri con molti schemi di progettazione (in alcuni modelli saranno ancora specifici per OO):

• Guarda Libri POSA per esempi di architettura software
  • Informatica distribuita
  • Modelli per oggetti simultanei e di rete
  • Modelli per la gestione delle risorse
• Modelli di Fowler dell'architettura aziendale con online catalogo
• xUnit Test patterns con sito
• E naturalmente da dove provengono i pattern: modo di costruire senza tempo

Nella programmazione funzionale (in particolare Haskell), ci sono molti schemi e idiomi che non si adattano molto bene a OOP. I tipi di fantasma sono un esempio ben noto e puoi trovare molto altro su haskell pagina wiki su Idioms .

La programmazione modulare è molto popolare per le librerie numeriche e le applicazioni matematiche (il software numerico è notoriamente difficile da modellare usando Modelli orientati agli oggetti, soprattutto perché c'è poco da incapsulare).

Un buon esempio di pattern non OOP è il mio catalogo di pattern preferiti in assoluto: Modelli organizzativi di sviluppo software agile, di James O. Coplien . Questo libro non riguarda schemi software, riguarda le persone, un catalogo per la creazione di team di successo. Ogni manager dovrebbe leggere questo libro!

Mi piace pensare a Data Strucutres come code, elenchi collegati, alberi, grafici, ecc. come modelli. Definiscono determinati modelli per archiviare i dati e elaborarli. Possono sembrare primitivi rispetto ai più alti schemi di Gang of Four, ma sono comunque modelli. Voglio dire, cosa succederebbe se qualcuno implementasse uno stack come FIFO invece di un LIFO e viceversa per una coda e li chiamasse altrimenti?