Può troppa astrazione essere cattiva?

Le primissime parole di TC ++ PL4:

Tutti i problemi in informatica può essere risolto con un altro livello di riferimento indiretto, salvo il problema di troppi strati di riferimento indiretto. - David J. Wheeler

(David Wheeler era il mio consulente di tesi. La citazione senza l'ultima riga importante viene talvolta chiamata "La prima legge dell'informatica".)

Sì, sicuramente. Il fatto è che nessuna astrazione è perfetta. Tutti i dettagli del livello su cui si trovano le astrazioni sono lì per un motivo, e possono semplificare molte cose, ma se questa complessità non fosse necessaria a un certo punto, probabilmente non ci sarebbe in primo luogo. Ciò significa che a un certo punto, ogni astrazione sta andando a perdita in qualche modo.

Ed è qui che sta il vero problema. Quando le astrazioni falliscono, più ne hai stratificate tra il codice che hai scritto e quello che sta succedendo, più difficile è capire il problema e risolverlo, perché ci sono più posti in cui il problema potrebbe essere. E più livelli ci sono, più devi sapere per rintracciarlo.

Sì assolutamente.

L'analogia che mi piace usare per spiegare la programmazione è quella di un sarto. Quando si realizza un abito, un buon sarto lascerà sempre una piccola quantità di tessuto in posizioni strategiche all'interno del capo per consentire l'inserimento o l'uscita del capo, senza modificarne la forma o la struttura complessiva.

Good Tailor's non lascia più risme di tessuto ad ogni cucitura, solo nel caso in cui ti capiti di crescere un terzo braccio o di rimanere incinta. Troppo materiale nei posti sbagliati renderà inadatto il montaggio e indumento da indossare male, il tessuto extra si intrometterà semplicemente nell'uso normale. Per poco tessuto e il capo è incline alle lacrime e non sarà in grado di essere alterato per far fronte a piccole modifiche al fisico di chi lo indossa, effettuando il modo in cui l'indumento si siede.

Forse un giorno, il nostro buon sarto avrà il compito di realizzare un abito così stretto da cucire indossandolo. E forse il nostro buon sarto è invitato a indossare abiti premaman, dove lo stile e la vestibilità sono secondi al comfort e all'espansione. Ma prima di intraprendere uno di questi lavori speciali, un buon sarto sarebbe abbastanza saggio da rendere tutti consapevoli dei compromessi che sono stati fatti per raggiungere questi obiettivi.

A volte questi compromessi sono la strada giusta da seguire e le persone sono disposte ad accettare le loro conseguenze. Ma nella maggior parte dei casi, l'approccio di lasciare un po 'dove conta di più supererà qualsiasi beneficio percepito.

Quindi, riportando questo all'astrazione. È assolutamente possibile avere troppi livelli di astrazione, proprio come è possibile avere poco spazio. La vera arte del programmatore, come i nostri amici sarti, è di lasciare un po 'dove conta di più.

Ritrovarsi sull'argomento.

Il problema con il codice di solito non è astrazione, ma dipendenze. Come hai sottolineato, è il codice che collega gli oggetti discreti che è un problema, perché c'è una dipendenza implicita tra di loro. Ad un certo punto la comunicazione tra cose deve essere concreta, ma giudicare dove quel punto di solito richiede qualche congettura.

Detto questo "Micro" qualsiasi cosa è di solito un'indicazione che hai sovrascritto il tuo layout di oggetti e probabilmente stai usando Tipo come sinonimo di ciò che dovrebbe essere Dati . Avere meno cose significa anche meno dipendenze necessarie per comunicare tra loro.

Sono un grande fan della messaggistica asincrona tra sistemi per questo motivo. Si finisce con due sistemi dipendenti dal messaggio , piuttosto che l'uno dall'altro. Dando un accoppiamento meno stretto tra i sistemi di comunicazione. A quel punto, se hai bisogno di avere una dipendenza tra i sistemi, devi considerare se hai i bit che dipendono dai posti giusti. E spesso capita che tu non lo faccia.

Infine, il codice complicato sarà complicato. Spesso non c'è modo di aggirare questo. Ma il codice che ha meno dipendenze è molto più facile da capire di uno che si basa su vari stati esterni.

I feel that our goal is to provide good abstractions on the given domain model and business logic.

Ho una visione diversa: il nostro obiettivo è risolvere un problema aziendale. Le astrazioni sono solo una tecnica per organizzare una soluzione. Un'altra risposta usa l'analogia di un sarto che realizza vestiti. Ho un'altra analogia che mi piace pensare: uno scheletro. Il codice è come uno scheletro e le astrazioni sono le giunture tra le ossa. Se non hai giunture, finisci con un solo osso che non può muoversi ed è inutile. Ma se hai troppe articolazioni, finisci con una pila di gelatina sciatta che non riesce a reggersi da sola. Il trucco è trovare il giusto equilibrio - abbastanza articolazioni per consentire il movimento, ma non tanto che non ci sia una forma o struttura definita.