Due modi per progettare sistemi complessi: dall'alto verso il basso e dal basso verso l'alto

Question

Ho un sistema complesso da progettare. ho due modi:

1. top-down: io vi progettare molte interfacce e contratti. Afterwords, implementerò queste interfacce e scriverò un prototipo per verificare il design.

2. Bottom-up: Scriverò il codice per far funzionare il sistema. Afterwords, estrarrò interfacce e contratti dal codice solido. Le interfacce e i contratti distillati sono il mio design. È la regola "eseguirlo, renderlo corretto".

Qual è il modo migliore? Dal mio punto di vista, sceglierò Bottom-up. Perché Top-down è molto difficile, nessuno può progettare molte interfacce ad alto livello astratto, almeno è difficile per me. Quando scrivo una solida implementazione per verificare il progetto iniziale, ci sono molte cose irragionevoli che mi costringono a riprogettare da zero. Mentre uso Bottom-up, mi sento abbastanza "sicuro", può funzionare almeno.

Answer 1

Come altri hanno già detto, di solito è un mix. A livello più pratico, il seguente approccio di solito aiuta:

• Iniziare andando ABSTRACT Top-Down. Vale a dire, rompere il sistema/design in componenti logici per risolvere compiti. Ma non progettare interfacce finalizzate precise per quei componenti. Procedere in modo ricorsivo fino a quando alcuni componenti a cui si arriva sono di dimensioni "implementazione possibili" (ad esempio la dimensione di una singola funzione/metodo/classe)

• Quindi, passare all'elenco dei componenti risultanti dal basso verso l'alto e iniziare a progettare prima bozza di interfacce/contratti.

• Quindi, passare attraverso l'elenco dei componenti risultanti Bottom-Up e iniziare a implementarli. Questo vi permetterà di:

  • Avere un lavoro e di codice verificabile immediatamente (non c'è bisogno di aspettare che sottostanti componenti da attuare per testare)

  • Si può sintetizzare la versione finale di interfacce/contratti per componenti di livello superiore in base alle esigenze dei componenti di livello inferiore già completati.

Answer 2

Tranne nella maggior parte dei progetti banali niente è mai così semplicistico. Trovo che la maggior parte dei progetti richieda una combinazione di entrambe le metodologie per affinare.

Answer 3

Personalmente preferisco anche Bottom up, in primo luogo perché si dimentica sempre qualcosa quando si esegue il top-down e quindi è necessario correggerlo e in secondo luogo perché almeno nel mio caso ottengo molte buone idee per il sistema completo durante la progettazione del singolo componenti dal basso.

Saluti, Lorenz

Answer 4

Nel mondo reale è quasi impossibile utilizzare queste metodologie semplicistiche per sistemi di progettazione. Dovresti usarli entrambi in più iterazioni.

Ma anche questa è una risposta semplicistica.

Answer 5

A mio parere, progettazione top-down è più naturale di un bottom-up. Ad esempio: quando si progetta un sistema, si definiscono primariamente le sue funzionalità (interfacce di progettazione e contratti), quindi si specificano le entità del sistema, si implementano le relazioni tra loro e così via ... Certamente, la progettazione top-down è più difficile di bottom-up, e richiede sviluppatori esperti.