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

Un po 'ispirato a questa domanda: per quali problemi comuni la programmazione funzionale non è adatta? - ma comunque una domanda che ho sempre desiderato, ma che avevo troppa paura di porre.

Sono stato in ... beh, chiamiamolo sviluppo software di ingegneria praticamente per tutta la mia vita, e in tutto quel tempo, anche se OO era sempre stato lì (beh, la maggior parte di quel tempo) non ho mai avuto bisogno di usare "i suoi modi", né per imparare quel paradigma. Abbiamo sempre usato strutture di programma piuttosto semplici, routine / funzioni / moduli e sebbene sia contrario alle migliori pratiche odierne la gestione di quei programmi (programmi fino a circa 300k LOC, niente di troppo grande) non si è mai rivelato difficile, per non dire impossibile.

Quindi volevo chiederti: quali sarebbero i problemi per i quali il paradigma orientato agli oggetti non sarebbe una buona scelta? Rispetto alla programmazione procedurale?

La programmazione orientata agli oggetti è una programmazione procedurale. La cosa che orienta gli oggetti OO è, come menziona Robert Harvey in un commento, che OO estrae i dati in un modo particolare (vale a dire: 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 eseguono sui dati e non è necessario disporre di implementazioni variabili dei dati. Detto questo, ci sono cose che puoi fare per avvicinare i due.

Il valore principale di OO è che fornisce il disaccoppiamento tra i componenti del sistema, facilitando la scrittura di codice DRY e l'adattamento a tipi specifici di modifiche che si prevede di progettare. Il costo è che aggiunge livelli 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 aiutati dal disaccoppiamento fornito dal tuo progetto). È quindi una perdita di tempo per qualsiasi sottoproblema in cui non è necessario il disaccoppiamento che fornisce. In particolare, è una perdita di tempo se si può facilmente scrivere codice DRY senza di esso e non anticipare eventuali modifiche ai requisiti specifici che trarrebbero beneficio dal forte disaccoppiamento fornito da OO.

concorrenza: il meccanismo di blocco sembra un po 'problematico; solo alcuni sviluppatori molto bravi vengono messi al lavoro sulla parte threading dei progetti

estensione: non so quanto siano estendibili le lingue OO correnti. so solo che Java è male. pertanto i DSL (linguaggi specifici del dominio) devono essere implementati come Frameworks. Il clojure invece (che è funzionale), ha macro.

La maggior parte dei programmatori, esperti di OO o no, usa concetti come astrazione, nascondimento di informazioni e interfacce nel loro codice. I linguaggi OO lo rendono semplicemente più semplice poiché questi concetti sono già integrati. Non devi inventarli tu stesso.

Un algoritmo core come qsort()usa le astrazioni per il confronto di oggetti arbitrari. fread()utilizza un'interfaccia per sottrarre i dettagli del flusso, ecc.

Da quel punto di vista trovo difficile trovare un problema particolare che sia meglio risolto con un approccio non OO.

Penso che quando si creano sistemi che combinano altri sistemi tramite API Web (resto, xmlprc, semplice arricciatura / wget) è possibile scrivere involucri OO ma è chiaramente solo una comodità. Se il servizio Web da utilizzare è semplice ed è solo una o due righe, OO è troppo. Se d'altra parte si finisce per dover avvolgere una complessa API web (come Amazon AWS per esempio), allora è bello avere una libreria wrapper (come boto in Python per AWS).

Pensieri?

I linguaggi PURE orientati agli oggetti non sono adatti per molti casi. Perché ci sono alcuni criteri da soddisfare per essere puro linguaggio orientato agli oggetti. Vedi-
/programming/250062/what-is-meant-by-the-term-true-object-orientation/250098#250098

Ma i linguaggi di programmazione più utilizzati sono multi-paradigma. Incorporano molte funzionalità non OO per affrontare vari tipi di problemi di programmazione e sviluppo. C ++, C #, Java o Ruby hanno tutte funzionalità non OO. Quindi, possono affrontare problemi in cui pure-OO non è bravo.

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 di metodo e i protocolli tra gli oggetti possono modellare le relazioni dinamiche tra entità.

Ho trovato che fosse un modo utile di produrre un modello DRY in grado di rappresentare in modo chiaro le regole e il comportamento della tua applicazione in un modo che è disaccoppiato da problemi tecnici (come l'uso di un database, una coda di messaggi o il infatti è 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 dell'applicazione.

Quindi, se questo è ciò in cui è orientata la programmazione orientata agli oggetti; a cosa non va bene? Bene, tutto ciò 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 meglio espressibili 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 permetterci 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 viene spesso utilizzato un approccio funzionale , poiché le sue pure funzioni consentono un ragionamento matematico più diretto.