OOP a paradigma singolo porta all'inversione dell'astrazione?

Question

Per quelli di voi che non hanno familiarità con il concetto, l'inversione dell'astrazione è l'implementazione di costrutti di basso livello sopra costrutti di alto livello, ed è generalmente considerata una cosa negativa perché aggiunge sia complessità inutile che spese inutili . Naturalmente, questa è una definizione soggettiva in qualche modo imprecisa.

Secondo te, la programmazione in un linguaggio OOP a paradigma singolo in cui tutto deve far parte di una classe e cose come puntatori non esposti, come Java o C #, porta inevitabilmente all'inversione dell'astrazione? In tal caso, in quali casi?

Answer 1

Singolo paradigma qualunque cosa viola il Primo Comandamento delle Astrazioni, che poche persone sembrano conoscere e anche meno preoccuparsi.

Non ti farai alcuna astrazione che non può essere ignorata se necessario, che il tuo codice sia libero da brutte inversioni di astrazione.

Qualunque sia il tuo paradigma, una volta che inizi a scrivere un codice non banale per risolvere i problemi del mondo reale, finirai con alcune cose che non si adattano molto bene al paradigma. Se dichiari che quel paradigma è tutto ciò che c'è, questo è quando le cose diventano brutte.

Per mescolare un paio di metafore, quando tutto ciò che hai è un martello, tutto inizia a sembrare un piolo, e se tutti i tuoi buchi sono rotondi e improvvisamente finisci con alcuni pioli quadrati e non hai seghe, (solo mazze), hai un problema.

Non c'è pranzo libero. Tutto è un compromesso. Il codice più semplice diventa scrivere, più diventa difficile per qualcun altro leggere e mantenere, o per te o per chiunque eseguire il debug quando si verificano problemi al di sotto del livello di astrazione a cui stai lavorando. (E alla fine, perché nessuna astrazione è perfetta .

Questo è il difetto fondamentale con " utile " tecnologie e paradigmi come codice gestito, garbage collection, compilazione JIT e "tutto è un oggetto" fiat. Impongono un livello di astrazione di base che non ti è consentito raggiungere al di sotto e quando qualcosa va storto al di sotto di quel livello, non c'è nulla che tu possa fare al riguardo. Sei bloccato lavorando su una cattiva astrazione perché non puoi ripararla.

Answer 2

i veri programmatori possono scrivere FORTRAN in qualsiasi lingua

in altre parole, non è la lingua, è il programmatore

Answer 3

Java e C # hanno metodi statici equivalenti alle funzioni, quindi il linguaggio non ti impone nulla.

Detto questo, una volta che ho avuto OO, non ho avuto alcun desiderio di passare a un altro stile di programmazione.

Se il tuo semplice livello OO copre qualcosa di complesso, suggerisco che probabilmente è il tuo codice a costituire un problema. Se OO è fatto nel modo giusto, dovrebbe essere semplice fino al metallo.

Answer 4

Non credo che un linguaggio come Java o C # ne risenta in modo tangibile, semplicemente perché le librerie che accompagnano il framework sono così ricche che la necessità di entrare in un altro paradigma non lo è veramente richiesto per la programmazione generale.

Detto questo, le librerie avanzate possono tuttavia soffrire di inversione di astrazione, poiché le implementazioni interne sono spesso nascoste o le classi chiave sono sigillate, gli sviluppatori che tentano di estendere queste librerie sono spesso costretti a ri implementare / replicare funzionalità per utilizzare con successo i punti di estensione forniti dalla libreria di classi base - questo non è tanto un problema di linguaggio, quanto una scelta consapevole fatta dallo sviluppatore delle librerie di classi base, per evitare di esporre funzionalità che potrebbero essere fragili o cambia spesso con le nuove versioni di .Net Framework / JDK.

Anche perché .Net Framework / Java Runtime entrambi consentono l'interoperabilità con altre lingue in cima al runtime comune, la capacità di indirizzare altri paradigmi (come la programmazione funzionale, i linguaggi dinamici ecc.) può anche fornire un'altra via per staccarsi dai vincoli del singolo paradigma.