Esiste una classificazione canonica o favorevole dei problemi di progettazione del software?

Naviga le tue risposte
6

La domanda sembra essere abbastanza vaga, quindi lasciatemi fare un po 'di background:

Ho dato un po 'di pensiero al concetto di design pattern e sono incappato nella classificazione usata dalla Gang of Four:

  • Modelli creativi
  • Modelli strutturali
  • Modelli comportamentali

Poiché i modelli di progettazione sono intesi come soluzioni per problemi di progettazione comuni, la classificazione dovrebbe applicarsi non solo ai modelli ma anche ai problemi sottostanti.

In qualche modo la classificazione sembra avere un senso e trovo difficile capire un problema di progettazione che non può essere inserito in una di queste categorie. D'altra parte lo trovo in qualche modo arbitrario.

La creazione non è un tipo di comportamento? A volte non dipende dal punto di vista se qualcosa si classifica come comportamentale o strutturale? Perché ci sono schemi creazionali ma non "distruttivi"?

Questa classificazione è un'invenzione della Gang of Four o è già stata usata in precedenza? Può essere derivato da qualche teoria? Ci sono alternative?

Questa domanda è correlata al mio precedente , differisce in due aspetti:

  • Riguarda lo schema di classificazione e non i modelli stessi.
  • Non si tratta di schemi ma dei problemi di progettazione che devono essere risolti dai modelli.
posta Frank Puffer 27.11.2016 - 20:09
fonte

3 risposte

11

L'idea sbagliata fondamentale è che per un dato problema c'è un determinato schema.

I pattern non sono lezioni su come codificare. Sono un vocabolario che usiamo per descrivere gli schemi che riconosciamo nel codice.

Posso risolvere qualsiasi problema in modo da evitare qualsiasi modello attualmente documentato. Se lo faccio, mi divertirò molto a spiegare come funziona il mio codice a chiunque altro.

È vero che le scelte di modello sono influenzate dal problema, ma sono anche influenzate dal linguaggio (e dalle sue carenze), ma per lo più sono una questione di stile personale.

Ogni collezione di pattern è incompleta proprio perché chiunque può crearne una nuova. Quello che hai imparato sono semplicemente quelli popolari.

I popolari sono buoni a sapersi perché posso dirti: "oh, quella classe è un decoratore, sai, lo schema decoratore?" senza dover entrare nei dettagli sulla composizione delle funzioni, le interfacce e la delega.

Creazionale significa semplicemente che il punto di questi schemi è costruire (inizializzare) alcuni oggetti.

Structural significa semplicemente che il punto di questi pattern è creare una struttura dati.

Behavioral significa semplicemente che il punto di questi pattern è comportarsi nel modo in cui un caso d'uso ha bisogno che il programma si comporti.

Questi sono obiettivi molto diversi che non hanno nulla a che fare con la classificazione di un problema. Sono parti della soluzione di uno. Se il problema sta passando dal punto a al punto b, questi ti dicono come costruire un'auto, navigare in una mappa e ottenere una patente di guida.

E va tutto bene ma puoi camminare se vuoi.

    
risposta data 27.11.2016 - 23:08
fonte
7

Il software mangia il mondo. Quindi, la tua domanda stimolante sembra tagliare l'universo in pezzi di lego predefiniti. Diversi autori hanno opinioni diverse su cosa potrebbero essere questi pezzi:

  • GoF ha utilizzato 3 categorie principali che risolvono i problemi di progettazione di classe usuale
  • Martin Fowler ha scritto un libro interamente dedicato a " Patterns for Enterprise Application Architecture ", che identifica diverse categorie di schemi per la progettazione di architetture software aziendali. Questi sono suddivisi in categorie specifiche come la logica del dominio, l'origine dei dati, la mappatura relazionale degli oggetti, la mappatura dei metadati, la presentazione web, ecc ...
  • POSA (aka "Patten Oriented Software Architecture") è una raccolta di 4 o 5 libri di Buschmann & al che identificano schemi architettonici per una gamma specifica di problemi come la gestione simultanea di oggetti, la gestione delle risorse, il sistema e l'elaborazione distribuita
  • Esistono molti altri libri su modelli specializzati (esempi di modelli di integrazione del software)
  • I linguaggi di programmazione hanno anche alcuni idiomi che possono essere visualizzati come modelli di basso livello (ad esempio RAII in C ++ o flussi di input / output in C ++, Java e altri linguaggi orientati agli oggetti).

Il fatto è che queste categorizzazioni non sono tutte allo stesso livello di astrazione. Possono sovrapporsi ulteriormente.

Trovare una categorizzazione generale di tutti i problemi software sembra quindi ambizioso come trovare un linguaggio di programmazione generale che si adatti idealmente a tutte le esigenze di programmazione. O un metodo universale di analisi del software in grado di scomporre qualsiasi problema di programmazione in pezzi predefiniti.

Questo non è possibile: questo potrebbe essere fatto per problemi noti come questi libri hanno mostrato. Ma ci sono così tante nuove aree o tecnologie nello sviluppo di SW e così tante interazioni tra tutte le diverse parti. Temo che non troverai una classificazione così generale.

    
risposta data 28.11.2016 - 00:45
fonte
2

I pattern GoF non sono un elenco completo di pattern software, né sono intesi a fornire un framework generalizzato per risolvere problemi di calcolo o scrivere un'applicazione.

Per la maggior parte, i pattern GoF sono soluzioni alternative per problemi in alcuni linguaggi di programmazione, e questo è tutto ciò che sono.

Le tre categorie di pattern GoF:

  • Modelli creativi
  • Modelli strutturali
  • Modelli comportamentali

sono solo termini che gli autori hanno compensato per il loro libro, in modo che possano concettualmente separare gli schemi in diversi contenitori.

    
risposta data 27.11.2016 - 20:35
fonte

Leggi altre domande sui tag

La manutenzione del codice è in genere un progetto speciale o è considerata parte del lavoro quotidiano? Qual è la differenza tra incapsulamento e alta coesione?