Il paradigma di programmazione orientata agli oggetti è obsoleto in quanto anti-modulare e anti-parallelo? [chiuso]

Tieni presente che le esigenze di Harper per insegnare un corso introduttivo di CS sono molto diverse dalle esigenze di un progetto di vita reale . Il suo compito è insegnare concetti fondamentali (ad esempio modularità, parallelismo, induzione) alle matricole. In quanto tale, è molto importante che la lingua (e il paradigma) scelti possano esprimere questi concetti con la minima certezza (sintattica e concettuale) possibile. Familiarità, supporto degli strumenti, librerie disponibili, prestazioni di esecuzione, ecc. Sono completamente irrilevanti in questo contesto. Quindi tieni questo a mente quando consideri quanto segue ...

La vista che OO è anti-modulare deriva dal gran numero di dipendenze di altre classi e anche gli oggetti di classi ben progettate tendono a finire. Che questo sia un problema - anche agli occhi dei sostenitori di OO - diventa chiaro quando si osserva la proliferazione dei quadri di Iniezione delle Dipendenze , articoli, libri e post sui blog negli ultimi anni (anche l'ascesa di i mock e gli stub sono interessanti).

Un altro suggerimento è la importanza dei modelli di progettazione e la complessità di implementarli - rispetto ad altri paradigmi di programmazione - ad es. Fabbriche, Builder, Adapter, Bridge, Decorator, Facade, Command, Iterator, Mediator, Observer, Strategy e Template Method e forse il Composite sono tutti in qualche modo correlati al miglioramento della modularità del codice OO.

Anche l'ereditarietà è problematica (es. il problema di classe di base fragile ) e il sottotipo (seducente) seducono l'implementazione di un algoritmo tra più classi, dove i cambiamenti possono propagarsi attraverso l'intera catena ereditaria ( su e giù!).

L'accusa di essere anti-parallel è correlata all'enfasi dello stato rispetto al calcolo (alias mutevolezza e immutabilità). Il primo lo rende maggiormente coinvolto nelle dipendenze espresse delle subcomputazioni (che è il punto di vista di Harper sul parallelismo!) Poiché di solito non si può dedurre dalla posizione in cui è gestito lo stato (ovvero il file, dove l'istanza variabile è dichiarata) che gli attori esterni cambieranno in quel momento.

L'enfasi su immutabilità e computazione rende molto più facile esprimere le dipendenze delle subcomputations, poiché non esiste una gestione dello stato, solo funzioni / calcoli che sono combinati nel punto in cui si desidera esprimere le dipendenze delle sottocom- puzioni.

Questa è probabilmente una pretesa audace da fare, ma in qualche modo sospetto, questo Robert Harper non è mai realmente ha scritto un vero e proprio software nella sua vita. Tutto ciò che sembra riguardare è ML e sistemi di tipo statico. Per quanto possa essere un grande contributo, non vedo come le sue affermazioni sull'OOP abbiano rilevanza.

Questo articolo non è controverso. La polemica implica esame, discussione e discussione. Quello che hai qui è un accademico ignorante che emette due accuse abbastanza fondamentali in una sola dichiarazione, senza preoccuparsi di fornire argomenti.

1. L'affermazione che l'OOP è anti-modulare è solo un'assurdità. Non so nemmeno come rispondere ad esso, non solo non sono stati forniti argomenti ma anche OOP progettando è un approccio per stabilire la modularità con accoppiamento molto basso tra i singoli moduli attraverso l'incapsulamento e l'astrazione.

2. Affermare che OOP è anti-parallelo dimostra semplicemente una mancanza di comprensione. OOP non blocca alcuna decisione sulla concorrenza. OOP impone solo di nasconderli: se è stato creato correttamente, non si può dire se l'implementazione di un oggetto sia parallela o meno.
   Quindi, in definitiva, l'OOP e la programmazione parallela sono ortogonali. Il modello dell'attore è un modello elegante per la concorrenza che può essere direttamente riflesso in un sistema di oggetti (ma non è necessario), fornendo una combinazione formidabile di entrambi.

Il problema con OOP è che poche persone lo comprendono effettivamente nel senso definito da Alan Kay .

1. OOP è un approccio. In alcuni linguaggi viene implementato utilizzando i pattern, in altri è possibile utilizzare direttamente gli idiomi di linguaggio incorporati (ad esempio Ruby, Objective-C, Smalltalk, Io ).
2. Contrariamente a quanto si crede, l'OOP non riguarda le classi. Riguarda oggetti e oggetti riguardano il passaggio di messaggi o un modo altrettanto incerto di incapsulamento e astrazione.

Questo è il motivo per cui Java sta per OOP quali bastoni appuntiti sono per il combattimento navale. Questo vale anche per molti altri cosiddetti "linguaggi OOP", ma la cosa su Java è che sembra essere una credenza comune nelle università, che Java dovrebbe essere usato per insegnare OOP.

Sono d'accordo con tutti coloro che pensano che le introduzioni a OOP con Java dovrebbero essere rimosse dai curricula CS. Penso anche che le persone che chiaramente mancano di una comprensione fondamentale dell'OOP non dovrebbero insegnarlo. Quindi è probabilmente meglio se Bob si attenga alla ML per i suoi corsi e semplicemente insegni ciò di cui ha una chiara comprensione.
In questo momento OOP è più un'etichetta alla moda, che alle persone piace attenersi a tutto. Ciò nuoce alle OOP e dice persone. OOP non è obsoleto. L'età d'oro di OOP deve ancora venire, quando le persone capiscono finalmente di cosa si tratta non (ad esempio, risolvendo ogni possibile problema usando la parola chiave class 500 volte).

Ottieni fanatici di ogni striscia.

La programmazione orientata agli oggetti non è un proiettile d'argento. Non è mai stato. Quello che è, è una vittima di hype. Inevitabilmente, le persone si ammalano del clamore e inizia a svilupparsi un contraccolpo (indipendentemente dall'utilità effettiva del paradigma).

Tra vent'anni non c'è dubbio che avremo qualche altra reazione contro la programmazione funzionale.

Non posso rispondere a questa domanda per intero perché si può solo intuire in secondo luogo i vaghi pensieri del suo autore. Sospetto strongmente che questo articolo stia per causare imbarazzo al suo autore. Non c'è nulla riguardo a OOP che suggerirebbe che non è né modulare né parallelo:

Modularità : un aspetto importante di OOP è che è davvero modulare (ma la modularità significa cose diverse in contesti diversi). Quindi, indipendentemente dal fatto che l'autore stia parlando di generalizzazione o programmazione statica, non è corretto.

Parallelizzazione : come per la programmazione parallela, la maggior parte dei framework ha supportato gli interupts, quindi il threading e ora la parallelizzazione corretta, come quello che vediamo in .Net framework 4.0 e nei linguaggi OOP che vi si attaccano.

Ho il sospetto che l'autore sia diventato una vittima della moda in quanto vi è un equivoco sul fatto che la programmazione funzionale e l'OOP si escludano a vicenda nell'uso. Esistono stili funzionali nei linguaggi OOP ben documentati, ad esempio, Oliver Sturm ha pubblicato in quest'area.

L'autore sostiene che l'OOP è troppo difficile da comprendere per i programmatori di matricole, il che può essere vero, anche se ne dubito, dati i requisiti di ammissione per la CMU! Le affermazioni anti-modulare e anti-parallelo possono essere vere in un contesto ristretto rispetto ai linguaggi puramente funzionali, ma non sono certo una condanna dell'intero paradigma (che sembra funzionare bene per coloro che sanno come usarlo).

Il curriculum proposto insegnerebbe la programmazione funzionale in una classe, la programmazione imperativa (procedurale) in un'altra classe e le strutture dati in un'altra classe. Una volta che una matricola ha imparato queste 3 cose, lui / lei dovrebbe essere pronto per imparare OOP.

Personalmente penso che sia eccessivo, ma gli accademici amano provare cose nuove ed estreme. Come contrappeso, il MIT era solito (e poteva ancora) insegnare tutti i principali paradigmi di programmazione in una lezione di matricola.

Stranamente, entrambe le scuole hanno prodotto alcuni ottimi programmatori. Vai a capire.