Come decidere quali classi sono necessarie per il sistema

If I take agile (TDD) approach, there are still many ways to achieve the key requirement by making it testable.

Sì, tuttavia, quando prendi le decisioni sbagliate, ci sono alcuni segnali piuttosto sfacciati.

Scoprirai molto rapidamente che hai classi in cui non c'è nulla da testare. Quando li trovi, ripensa il tuo design, probabilmente non hai bisogno di quella classe.

D'altra parte, troverai anche il codice in cui senti che stai nuotando in melassa mentre provi a scrivere i test. Di nuovo, ripensa il tuo progetto, probabilmente ha bisogno di un livello di astrazione che non hai ancora.

Negli altri casi, troverai test che falliscono a intermittenza. Di nuovo, questo richiede un ripensamento. I test dovrebbero sempre passare o fallire sempre contro lo stesso pezzo di codice; se dipendono dalla situazione, allora devi astrarre qualcosa.

Ci sono altre lezioni da imparare ma, come è stato sottolineato, le imparerai di più per tentativi ed errori piuttosto che leggendo.

Tuttavia, se vuoi davvero un esempio da leggere, ce n'è uno particolarmente valido in Sviluppo software Agile di Robert C Martin , Principles, Patterns and Practices , in cui due sviluppatori si associano per codificare una scheda di punteggio bowling in stile TDD. Riusciranno a cadere in molte trappole di design "ovvio" e ti mostreranno come adattare il tuo design di conseguenza.

I libri sono scritti sulla teoria perché in pratica funziona solo per quell'esempio pratico. Suggerirei di realizzare molti piccoli progetti. O analizzando l'architettura di grandi progetti.

Se ti senti paralizzato dall'indecisione sui molteplici modi in cui potresti risolvere un problema, scegli semplicemente uno. Inizia dall'inizio, lavora nel mezzo e fermati quando raggiungi la fine. È probabile che scarterai la tua decisione originale e andrai con qualcos'altro, ma va bene. Pianifica un po ', lavora un po'. Troppo o troppo poco di entrambi sarà dannoso per il tutto.

Tic tac toe: prima hai bisogno di una tavola. Hai bisogno di molte altre cose, ma stai avendo problemi a partire, quindi la tavola è un buon punto di partenza come qualsiasi. Una scheda ha una matrice 2D di campi che possono avere tre stati. Ha bisogno di testare per le condizioni di vittoria. Ha bisogno di test per le cravatte. Queste sono cose che potrebbero essere fatte da qualche altro oggetto, ma stiamo iniziando con la scacchiera. Ciò potrebbe cambiare in futuro, ma per ora va bene.

Leggi questo: link .

E questo: link

E questo: link

Aiuta a capire come arrivare ad una ragionevole allocazione di responsabilità per una definizione di classe.

Ci sono sicuramente molti modi per progettare un sistema software. Alcuni disegni sono migliori di altri e alcuni potrebbero essere ugualmente buoni. Inoltre, i sistemi software crescono e si evolvono, il che significa che un design che è buono oggi potrebbe non essere così bello domani, quando sarà necessario aggiungere una nuova funzione.

Tuttavia ci sono principi e pratiche collaudati che ti aiutano a capire come decomporre il tuo problema in classi, oggetti, algoritmi, schemi, ecc. Ricorda, scrivere software è un processo iterativo, proprio come scrivere un libro. Non hai mai capito bene al primo tentativo. Invece, inizi con una brutta copia e continui a raffinarlo. I due concetti principali sono coesione e accoppiamento . Volete che i vostri moduli abbiano un'elevata coesione, esemplificata dal principio di responsabilità singola , e basso accoppiamento. Vuoi anche che il tuo design abbia senso per gli altri, in modo che possa essere facilmente compreso, implementato o aumentato.

Un buon approccio è disegnare un diagramma di alto livello del tuo sistema, e. g. usando UML. Se sembra un disastro, o se alcune parti di esso non hanno senso, probabilmente vorrai refactoring. Potrebbe anche aiutare a spiegare il tuo sistema a qualcun altro. In primo luogo, probabilmente vedrai i difetti del design da solo mentre parli. Secondo, se altre persone trovano difficile seguire il tuo design, dovresti probabilmente correggerlo. Un altro modo è quello di spiegare il tuo progetto per iscritto. Quindi leggilo. ha senso per te? Quindi dagli ad altri per leggere. Ha senso per loro?

La progettazione del software diventa più semplice con l'esperienza. Sviluppa un senso per gli odori di codice , che ti indicano potenziali difetti di progettazione. Tuttavia, anche se hai scritto codice per decenni, è comunque una buona idea spiegare i tuoi disegni ad altre persone e vedere se possono seguire il tuo codice.

Per essere più concreti, consiglio vivamente i seguenti due libri: Pulisci codice di Robert C. Martin, e Refactoring di Martin Fowler.

Non esiste un "one way" per progettare un software. Ci sono un sacco per ogni caso.

La creazione di un BDUF (grande design in primo piano) è di solito una pessima idea, perché si sovrascrivono o si preparano per cose che non verranno mai utilizzate, o addirittura rendendo le future implementazioni pulite impossibili, retrospettivamente.

Raccomando di iniziare con un progetto evolutivo top-down. Tieni sempre a mente il prossimo pezzo di più alto livello e i suoi collaboratori immediati, creando istanze di classi che non esistono ancora come ritieni necessario nel codice del chiamante e quindi implementando tali classi una volta che sai che il modo in cui il tuo codice è implementato le richiede veramente.

La cosa importante da ricordare è che, man mano che avanzi, aggiusti e rimuovi costantemente la duplicazione.

Usando TDD puoi fare tutto ciò che ho detto e rendere tutto controllabile.