Quando scrivere codice astratto e quando essere più specifico?

In che modo un pittore sa se è troppo o troppo poco di viola?

Mescola i colori, prova un colpo, crea alcuni schizzi e vede cosa succede. Quindi regola le proporzioni fino a quando l'intero disegno sembra bello e irradia armonia.

Facciamo lo stesso con il codice. Otteniamo un'idea di implementazione per la prima volta, riflettiamo su di essa, analizziamo i suoi lati forti e quelli della settimana, quindi proviamo a vedere se funziona. Quindi modifichiamo l'idea in un processo iterativo per regolare le proporzioni di astrattezza, incapsulamento, polimorfismo e quant'altro fino a quando non sembra giusto e funziona se necessario.

Scrivi prima il codice concreto.

Scrivi codice astratto quando devi perché semplifica il codice concreto.

È più facile iniziare con il cemento e trovare le astrazioni dopo aver studiato ciò che è simile e diverso sul cemento.

Scrivi codice astratto quando scrivi le librerie e devi generalizzare la funzionalità in modo che funzioni in un'ampia varietà di condizioni.

Ma scrivere le biblioteche in questo modo è difficile. In un'applicazione normale (ad esempio, una linea di applicazione aziendale), questo tipo di generalizzazione è considerato una forma di "ottimizzazione prematura", generalmente caratterizzata come "Non ne avrai bisogno" (YAGNI).

C'è un punto critico in cui il codice ripetitivo richiede la progettazione di una soluzione più generalizzata. Ma in genere questo tipo di refactoring per rimuovere la ridondanza è molto più semplice della scrittura di una libreria generalizzata.

Alla fine, la complessità aggiuntiva richiesta per implementare soluzioni astratte deve essere giustificata dalla flessibilità che offrono.

Leggendo la domanda, direi che puoi essere sia astratto che specifico. È solo una questione di contesto, usa la rappresentazione più astratta possibile in ogni contesto.

Per la tua app giocattolo specifica, ChangeItem è la rappresentazione più astratta delle modifiche. Quindi ottieni più specifiche con DirectoryChangeItem e FileChangeItem , per ereditarietà. Puoi utilizzare un modello composito per modellare l'albero. Quando vuoi visualizzarlo puoi usare le rappresentazioni specifiche e quando lo attraversi puoi usare la rappresentazione astratta.

E per dare una risposta concreta alla domanda: sii il più specifico possibile finché non senti di aver bisogno di un altro livello al di sotto di quello.

La regola empirica che seguo, che è abbastanza comune, è che non dovresti cercare di astrarre qualcosa finché non ti ritrovi a scriverlo per la terza volta.

La prima volta non si capisce il dominio del problema e si finisce col sovrasfruttare tutti i pezzi sbagliati. La seconda volta sei perfettamente posizionato per costruire la soluzione ideale per il tuo ultimo problema. La terza volta sei finalmente in una buona posizione per trovare astrazioni appropriate che ti aiuteranno su cose che devono cambiare, e non metterti in mezzo per ottenere le cose semplici.

Tipicamente l'astrazione è utile per combattere cose come la complessità, l'entropia, per rendere il tuo codice cibernetico, e anche ad una leggibilità di basso livello. Prima dovrei scrivere hardcode, SOLO se l'astrazione non è ovvia. La maggior parte dell'astrazione si verifica quando più di un'implementazione condividono lo stesso modello.

Pensa che l'astrazione sia la congruenza o l'unità di 2 o più Insiemi. Prendi un diagramma di Venn come un modello semplicistico: la parte in cui i cerchi si sovrappongono o, in altre parole, i Set si fondono.

Se ho due serie: A: {a, b, c, d, e} e B: {d, e, f, g, h}. Il punto in cui vorrei iniziare a cercare di astrarre è l'unità di A + B; {d, e} è dove astrarre. Allo stesso modo, se quelli nella differenza di A & B (AB o BA) sono isomorfe l'una con l'altra, il che significa che costa poco creare a, boc da f, g o h (e viceversa), quindi terrei l'astrazione nella parte posteriore della mia mente.