Design Patterns

Question

Eventuali duplicati:
How do you know when to use design patterns?

Come posso capire/prendere decisione su "Quando usare cosa Design Pattern"?

Quali sono i fattori da osservare mentre si prendono decisioni sull'utilizzo di un modello di progettazione appropriato in un luogo appropriato?

Answer 1

In generale, se lo stai facendo bene, c'è uno schema per questo. Potresti solo sapere che lo stai usando.

Se si sta facendo male, c'è un anti-pattern per questo. Ma tu sicuramente non sai che lo stai usando.

Answer 2

Gang of Four (GoF) modelli sono una buona risorsa.

Answer 3

Tutti i modelli ben definiti hanno sfondo, contesto e il problema risolto dal motivo.

L'intero punto di un modello è quello di dirti quando è appropriato.

Answer 4

Scopri l'eccellente libro "Emergent Design: The Evolutionary Nature of Professional Software Development". Ti mostra come finiamo con gli schemi di progettazione e ti forniremo buone istruzioni su come architettare il tuo codice.

Answer 5

Non è consigliabile impostare sempre il software per adattarlo a uno schema di progettazione, ma se corrisponde a uno lo si utilizza. In molti casi la maggior parte delle cose che fai avrà un modello di progettazione che è semplicemente un modello che è stato osservato da molte diverse implementazioni software come comuni.

Ad esempio se si dispone di un set di classi che devono essere tutte sincronizzate. Bene, questo funziona bene con il pattern Observer o Publish/Subscribe dove una classe è il notificatore e l'altra ascolta le notifiche. Observer pattern

Oppure dire che si desidera limitare l'utilizzo della memoria in un motore di gioco, è possibile creare un ObjectPool. Object pool

O forse si vuole semplificare una serie di oggetti in un API simplr quindi utilizzare il modello Facade: Facade pattern

Molte volte solo con modelli funzionali come l'incapsulamento o eredità vanno bene. Dipende dal problema Nella maggior parte dei casi, gran parte di ciò che si tenta di codificare verrà risolto in uno schema, ma i pattern non sono l'unico modo per codificare. In molti casi, inizi a progettare o hai bisogno e diventa un modello.

Ricordare i pattern originati dall'osservazione di molti tipi di problemi software, non è il punto di partenza ma il riflesso dell'architettura software.

Design pattern (computer science)

Molti campioni di modelli a dofactory.com: Design pattern tutorial by dofactory

Python design pattern: http://video.google.com/videoplay?docid=-3035093035748181693

Forzatura design pattern è come costringere OO. Dovrebbe venire naturalmente dai bisogni nel progetto attuale.

Answer 6

Trovo che se sto solo hackerando un programma, un buon uso di schemi di progettazione è quasi impossibile, ma, se si progetta il programma, allora si può guardare a ciò che si vuole fare e i modelli di progettazione iniziano a essere visti in la tua applicazione.

Ad esempio, se si vede che esiste una classe che dirige il flusso dell'applicazione, allora il pattern Controller ha senso.

L'altro modo di utilizzare modelli di progettazione è scrivere il programma, farlo funzionare, quindi refactoring utilizzando modelli di progettazione. Credo che Martin Fowler abbia scritto un libro su questo argomento, ma non sono favorevole all'autore.

In entrambi i casi è utile sapere che cosa si desidera fare per aiutare a decidere quali modelli funzionano meglio.