Come ci si avvicina alla progettazione della classe in OOP?

In tutta onestà, ha aggiunto "In divertimento" a tale affermazione.

Fino ad oggi, tendo ad iniziare con la modellazione di sistemi usando l'approccio "sostantivo e verbo", ma ho scoperto negli anni che TDD ci insegna che questo approccio attira l'attenzione sulla cosa sbagliata. In questo senso, il blogger ha un punto. Tuttavia, non sono sicuro che sia l'approccio alla colpa, piuttosto che il modo in cui le nostre menti funzionano.

Se vuoi provare una piccola sfida qui, smetti di leggere e prova a modellare il gioco Monopoli, usando la lingua inglese, quindi torna qui.

Sospetto che la tentazione sia di guardare immediatamente agli oggetti con cui interagiamo molto - la tavola, gli spazi, le carte, i dadi, i pezzi - ma non è quello il punto in cui va la maggior parte della logica. La maggior parte di questi oggetti sono completamente stupidi. Dati, se vuoi.

Ma non appena inizi a scrivere test, ti rendi conto di quale oggetto è di gran lunga il più importante in qualsiasi gioco: le regole.

Ricorda quel piccolo pezzo di carta che hai letto una volta quando hai iniziato il gioco e non interagisci più fino a quando non si verifica una disputa? La versione computerizzata non funziona in questo modo. Ogni singola cosa che il giocatore prova a fare, un computer consulta le regole e verifica se è autorizzato a farlo o meno.

Quando ci pensi, fai la stessa cosa ma poiché ci vuole tempo per leggere le regole basate sulla carta e il tuo cervello ha un ragionevole sistema di memorizzazione nella cache, consulta le regole nella tua testa. Probabilmente un computer troverà di nuovo facile leggere le regole, a meno che non siano archiviate nel database, nel qual caso potrebbe anche memorizzarle nella cache.

Ed è per questo che TDD è così popolare per guidare il design. Perché tende a indirizzare rapidamente la tua idea sui luoghi giusti:

Quando penso che scriverò alcuni test per il mio gioco Monopoly. Potrei guardare il mio set e provare a trovare gli oggetti. Quindi, abbiamo questi pezzi. Scriverò alcuni test per quelli.

Forse avrò una classe base MonopolyPiece e ogni tipo di pezzo deriverà da quelli. Inizierò con il DogPiece. Primo test ... ahh. In realtà, non c'è logica qui. Sì, ogni pezzo sarà disegnato in modo diverso, quindi potrei aver bisogno di un DogDrawer, ma mentre sono fuori dal gioco, voglio solo scrivere "D" sullo schermo. Alla fine renderò l'interfaccia utente.

Scopriamo alcune logiche effettive da testare. Ci sono molte di queste case e hotel, ma non hanno bisogno di test. Soldi, no Carte di proprietà, no. E così via. Anche la scheda non è altro che una macchina a stati, non contiene alcuna logica.

Scoprirai subito che hai tre cose in mano. Le carte Chance e Community Chest, una coppia di dadi e un set di regole. Queste saranno le parti importanti da progettare e testare.

L'hai visto arrivare quando hai scritto i nomi e i verbi?

Esiste, in effetti, un ottimo esempio in Principi e pratiche di Agile Principles di Robert Martin dove cercano di distribuisci un'app di Bowling Score Card usando TDD e trova tutti i tipi di cose che pensavano fossero ovvie classi che non valevano la pena di preoccuparsi.

Non ho mai trovato utili questi metodi per me. Infatti ho scoperto che usarli mi confonde di peggio. Dai un'occhiata a Coffee Maker di Robert C. Martin , non credo che utilizzi questo tipo di approccio.

Una cosa che mi dà fastidio è la soluzione a cui la persona si rivolge nell'articolo CRC a cui ti colleghi. La collaborazione cliente / ordine non è qualcosa che valuterò utile, non come scritto comunque. Non c'è nulla di particolarmente interessante in quel modello su un cliente che meriti lo status di classe. L'unica cosa interessante di essere un "cliente" è che ci sono uno o più ordini associati a quella Persona .

Anche il modello del college. C'è molto che può e probabilmente dovrebbe essere condiviso tra studenti e professori. Inoltre, cosa succede quando un professore tiene una lezione, come spesso viene concesso gratuitamente nei campus universitari?

Suppongo che potrebbe essere una pratica utile, un elemento nel toolkit di progettazione. Non penso che dovrebbe essere l'unico modo in cui ti avvicini al design almeno. Francamente, trovo l'approccio dell'analisi di commonality / variation più utile. Mi sembra di modellare molto da vicino ciò che facciamo nella classificazione delle astrazioni durante la vita di tutti i giorni.

Modifica: leggi solo la metà del secondo blog e devo dire che sono d'accordo molto. Dovrò leggere il resto e vedere cosa offre in termini di apprendimento.

La mia opinione è che le classi debbano essere aggiunte (e rimosse) durante la codifica per separare le preoccupazioni e ridurre le dipendenze. Essere fluenti nei modelli di progettazione è probabilmente una buona scommessa per vedere le possibilità di refactoring e semplificazione.

Le classi in generale, secondo la mia esperienza, non rientrano ordinatamente nelle categorie nome / verbo, ma piuttosto si finisce con un mix di classi nome / verbo insieme a diverse classi di pattern (fabbriche, singleton, schemi di strategia ecc.) e altre classi di manager che affrontano un aspetto della tua applicazione.

La cosa fondamentale è che il tuo obiettivo dovrebbe essere quello di riuscire a guardare una classe e dedurre cosa fa e modificarla modificando solo quella classe. Più codice per un aspetto della tua applicazione è distribuito tra le classi più diventa difficile seguirlo, gestirlo ed estenderlo.