Quali categorie di problemi di modellazione del software è l'orientamento all'oggetto altamente inadatto? [chiuso]

Prima di tutto, non confondere la modellazione OO con la programmazione OO. I linguaggi di programmazione più moderni sono più o meno OO e possono essere utilizzati per implementare la maggior parte dei progetti, indipendentemente dal fatto che siano stati derivati utilizzando la modellazione OO o meno. Posso scrivere un programma seguendo una progettazione relativamente procedurale (o guidata dagli eventi, o qualche altro stile) e utilizzo ancora le Collezioni Java con le loro pratiche interfacce OO.

Ora per la modellazione, direi di non utilizzare OO in domini in cui sono già stati stabiliti framework più specifici. Ad esempio, se si affronta un problema basato sugli eventi, allora ha senso descrivere il proprio progetto usando gli eventi (non le classi) come un elemento costitutivo e solo per l'implementazione (se si utilizza un linguaggio OO) decidere come mapparlo classi o oggetti. Ad esempio, potresti scoprire che tutti i tuoi eventi richiedono lo stesso insieme di metodi, quindi li implementerai utilizzando un'unica classe.

In base alla mia esperienza, in realtà è sempre meglio capire le nozioni di design usando concetti dal dominio dell'applicazione e solo nell'implementazione effettiva decidere cosa dovrebbe diventare una classe o una sottoclasse e quali sono i metodi importanti. Classi e metodi, a mio avviso, sono molto più utili per strutturare il codice che per strutturare il problema del cliente.

Ci sono molti modi per vederlo. Un modo è dal punto di vista dell'astrazione dei dati. (Ho intenzione di ignorare questo aspetto dal punto di vista dei paradigmi di programmazione, dal momento che @ Robert's answer fa già un buon lavoro.) Le due forme più popolari di astrazione dei dati in uso oggi sono Tipi di dati astratti e oggetti. (In realtà, c'è una terza forma piuttosto popolare: nessuna astrazione.)

La principale differenza tra ADT e Oggetti è che le istanze ADT nascondono la loro rappresentazione da istanze di altri tipi ma non da istanze dello stesso tipo, mentre gli oggetti nascondono anche la loro rappresentazione da altri oggetti dello stesso tipo. (Se hai familiarità con Java, questa è la differenza tra le classi e le interfacce, le classi definiscono gli ADT e le interfacce definiscono gli oggetti.)

Ciò significa che a causa del più alto livello di incapsulamento, OO ha il potenziale per essere più flessibile ed estensibile. Tuttavia, gli algoritmi che richiedono l'accesso alla rappresentazione di due oggetti sono semplicemente impossibili da implementare. Ad esempio, non è possibile concatenare in modo efficiente due elenchi collegati in doppia sequenza in OO, poiché è necessario accedere sia al puntatore% ca_de% della coda della prima lista sia al puntatore next della testa della seconda lista. Se chiami il metodo prev della prima lista, non ha accesso agli interni della seconda lista e viceversa, l'unico modo per farlo in modo efficiente è uno degli elenchi che espongono i suoi interni all'altra, cioè l'incapsulamento OO. (È possibile naturalmente concatenare due elenchi ripetendo il secondo, cioè fallo in O (n), ma non puoi farlo in O (1).)

Considera i tre pilastri dell'OOP:

1. Incapsulamento: la capacità di nascondere dati e istruzioni all'interno di un oggetto

2. Ereditarietà: la possibilità di creare un oggetto da un altro

3. Polymorphism: la capacità per oggetti di una classe derrived di sovrascrivere / estendere / ereditare proprietà e metodi da una classe base

Se questi benefici non offrono alcun valore reale per risolvere il problema in questione, si può sostenere che forse OOP non è la scelta ideale, o almeno non necessaria.

In pratica, il vantaggio che viene fornito con OOP ben progettato e ben scritto raramente giustifica il "sovraccarico" quando si lavora con applicazioni o applicazioni relativamente piccole che sono limitate alle risorse. In natura ho visto molti processi ETL costruiti in linguaggi come C # e Java che non seguono necessariamente il paradigma orientato agli oggetti. Sì, esiste una "classe" a causa dei vincoli di questi linguaggi, ma tutti i metodi sono resi statici ed esistono all'interno di una singola classe chiamata Programma. (Cs / java) che funge da punto di ingresso dell'applicazione.

Sinceramente è difficile pensare a situazioni in cui l'OOP è il peggiore di tutti i paradigmi di programmazione disponibili, ma ci sono casi in cui non è il paradigma più ideale. Si potrebbe dire che sì, un paradigma orientato agli oggetti non è sempre l'ideale per una situazione che si presta a un paradigma basato sugli eventi o procedurale, ma è difficile dire se sarebbe più o meno inadatto alla situazione che, diciamo, un paradigma funzionale.