Per quali problemi la programmazione orientata agli oggetti non è una buona scelta? [chiuso]

Programmazione procedurale orientata agli oggetti è . La cosa che rende OO orientato agli oggetti è, come dice Robert Harvey in un commento, che OO astrae i dati in un modo particolare (ad esempio: raggruppare le funzioni che operano su una struttura con quella struttura).

William Cook spiega bene la differenza tra oggetti e tipi di dati astratti.

Quindi, a rischio di sembrare facile, direi che gli oggetti non sono adatti per quando è necessario estendere facilmente il (numero di) operazioni che si eseguono sui dati, e non è necessario avere variazioni implementazioni dei tuoi dati. Detto questo, ci sono cose che puoi fare per portare i due più vicini.

Il valore principale di OO è che fornisce il disaccoppiamento tra i componenti del tuo sistema, rendendo più facile scrivere il codice DRY e adattarsi a specifici tipi di modifiche che progetti nel tuo progetto. Il costo è che aggiunge strati di riferimento indiretto, che possono rendere il codice più difficile da ragionare, meno efficiente e più difficile da modificare in modi imprevisti (i modi che non sono favoriti dal disaccoppiamento fornito dal progetto). È quindi una perdita di tempo per qualsiasi sottoproblema in cui non è necessario il disaccoppiamento che fornisce. In particolare, è uno spreco di tempo se puoi scrivere facilmente il codice DRY senza di esso e non prevedere alcuna specifica modifica dei requisiti che possa beneficiare del strong disaccoppiamento fornito da OO.

concorrenza: il meccanismo di blocco sembra un po 'problematico; solo alcuni ottimi sviluppatori sono messi al lavoro sulla parte thread dei progetti

estensione: non so in che modo sono estensibili le lingue OO attuali. solo sapere che Java è cattivo. per questo i DSL (lingue specifiche del dominio) devono essere implementati come Framework. Clojure d'altra parte (che è funzionale), ha macro.

La maggior parte dei programmatori, OO esperti o meno, utilizza concetti come l'astrazione, l'occultamento delle informazioni e le interfacce nel loro codice. I linguaggi OO rendono tutto più semplice poiché questi concetti sono già integrati. Non devi inventarli da soli.

Un algoritmo principale come qsort() utilizza le astrazioni per il confronto di oggetti arbitrari. fread() utilizza un'interfaccia per astrarre i dettagli dello stream ecc.

Da questo punto di vista trovo difficile trovare un problema particolare che possa essere risolto meglio con un approccio non OO.

Penso che quando costruisci sistemi che combinano altri sistemi tramite web apis (resto, xmlprc, plain curl / wget) puoi scrivere wrapper OO ma è chiaramente solo una comodità. Se il servizio web da utilizzare è semplice e si tratta solo di una o due righe, OO è troppo. Se invece finisci per dover avvolgere una web API complessa (come Amazon AWS per esempio), allora è bello avere una libreria wrapper (come boto in python per AWS).

Pensieri?

Le lingue orientate agli oggetti PURE non sono adatte per molti casi. Perché ci sono alcuni criteri da soddisfare per essere un puro linguaggio orientato agli oggetti. Vedi-
link

Ma i linguaggi di programmazione più diffusi sono multi-paradigma. Incorporano molte funzionalità non OO per affrontare vari tipi di problemi di programmazione e sviluppo. C ++, C #, Java o Ruby hanno tutti funzionalità non OO. Quindi, possono affrontare problemi a cui OO puro non è adatto.

La programmazione orientata agli oggetti può essere utilizzata per modellare il tuo dominio. Le classi possono essere utilizzate per rappresentare lo stato e il comportamento di entità, aggregati, collaborazioni, servizi all'interno del modello di dominio. Inoltre, le invocazioni e i protocolli del metodo tra gli oggetti possono modellare le relazioni dinamiche tra entità.

Ho trovato che sia un modo utile di produrre un modello DRY in grado di rappresentare in modo pulito le regole e il comportamento dell'applicazione in un modo che è disaccoppiato da problemi tecnici (come l'uso di un database o una coda di messaggi) , o il fatto che sia un'applicazione web). Un buon libro sull'argomento è Domain Driven Design

Una cosa importante da notare qui è che le "entità" che ho menzionato sopra non devono mappare su oggetti del mondo reale! Possono rappresentare parti astratte del dominio della tua applicazione.

Quindi, se questo è ciò che la programmazione orientata agli oggetti è buona; cosa non va bene? Bene, qualsiasi cosa in cui il modello di dominio non può essere espresso bene come oggetti. Ad esempio, alcuni programmi matematici (statistici, logici, ecc.) O tecnici (ad esempio un compilatore) sono espressi meglio in diversi stili. Ho scoperto che per le applicazioni del flusso di lavoro aziendale una combinazione di tecniche OO e DSL personalizzate è stata molto efficace nel consentirci di modellare i tipi di relazioni ed eventi che si verificano nei processi aziendali. Per la verifica del programma e il controllo automatico delle prove un approccio funzionale è spesso utilizzato, poiché le sue funzioni pure consentono un ragionamento matematico più diretto.