I paradigmi non OOP supportano concetti come l'incapsulamento?

Penso che la trappola in cui sei caduto qui stia pensando che esiste una definizione rigida di qualsiasi paradigma di programmazione (strutturato, orientato agli oggetti, funzionale, ecc.)

Se chiedi a due sviluppatori diversi che cosa significa OOP, otterrai due risposte diverse. Sì, come professione siamo d'accordo sul fatto che ci sono alcuni temi comuni come incapsulamento, nascondimento dei dati, ecc. Coperti da qualsiasi classe di ingegneria del software OOP al college.

Tuttavia , nel mondo reale, le cose non sono così semplici e precise, motivo per cui due sviluppatori daranno due risposte diverse. Forse sono esperti in diverse lingue che esprimono concetti OOP in modo diverso. I paradigmi linguistici tendono a sovrapporsi. L'ultima moda del 2013 o giù di lì sta incorporando la programmazione funzionale in linguaggi orientati agli oggetti attraverso chiusure o lambda. Java 8 è orientato agli oggetti o funzionale? Lo chiamerei object-oriented con un pizzico di funzionalità. Qualcun altro potrebbe descriverlo in modo diverso.

Is it that OOP is applied wrong?

No, il problema è che varie lingue esprimono i concetti di programmazione in modo diverso. Forse una lingua lascia un concetto di OOP, e un'altra lingua lo include, ma lascia fuori un diverso concetto di OOP. Le lingue sono in genere progettate per uno scopo: rendere semplice un determinato tipo di compito, a scapito di rendere più difficili altre attività. Non è né giusto né sbagliato, è semplicemente un compromesso nel mondo reale che è impossibile evitare.

Il mondo reale è non l'aula. O abbiamo bisogno di discutere i paradigmi di programmazione concettuale a livello astratto, o dobbiamo discutere di linguaggi di programmazione reali che sono costretti a fare dei compromessi per essere utili. Finché un linguaggio di programmazione è principalmente definito da una definizione astratta di OOP, possiamo includerlo in quel bucket.

However, lately the software world seems to be tilting in favour of other paradigms like functional programming.

Questo è discutibile. Innanzitutto, non vedo altri paradigmi oltre all'OOP e alla programmazione funzionale che sono discussi a grandi linee, quindi suppongo che possiamo dimenticare gli "altri paradigmi come" frase, parliamo di FP, nient'altro .

Le ragioni per cui la programmazione funzionale è diventata così popolare negli ultimi anni sono state discusse in altre domande qui in profondità, non ho intenzione di ripeterlo (vedi qui o qui , ad esempio). Ma, secondo me, non è perché "OOP è stato un grosso errore", o "Funzionale contro OOP si escludono a vicenda", è più come la gente che estende la sua cassetta degli attrezzi e cerca di ottenere il meglio da entrambi i mondi. Ok, ci sono sicuramente degli esperti che sono gli intransigenti che preferiscono l'uno rispetto all'altro, ma troverete quei ragazzi da entrambe le parti.

It makes me think, what about encapsulation and other OOP tenets? Are they wrong?

L'incapsulamento ha molti gusti diversi. I linguaggi di programmazione funzionale e i costrutti del linguaggio forniscono certe forme di incapsulamento, altri orientati agli oggetti. Se stai cercando esempi di incapsulamento con mezzi funzionali, inizia con chiusure .

Riguardo "altri principi": no, non sono sbagliati, ma per alcuni scenari come la parallelizzazione su larga scala, gli approcci funzionali probabilmente scalano meglio. Per altri scenari, come la creazione di framework di UI ben progettati, gli approcci di OOP sono probabilmente migliori (YMMV, non ho solo un esempio migliore disponibile). Inoltre, sono sicuro che per la maggior parte degli scenari del mondo reale dipende dalla conoscenza e dall'esperienza del team con il suo paradigma di programmazione preferito su come un determinato sistema verrà scalato.

Is it that OOP is applied wrong? For instance Alan Kay is noted for saying in the OOPSLA'97 Keynote: "I invented the term object-oriented, and I can tell you I did not have C++ in mind."

Sicuramente l'OOP viene spesso applicato in modo errato da molte persone, ma sono sicuro che lo stesso è vero per FP. E sarei stupito se John Mc Carthy (designer di Lisp) avesse in mente qualcosa di simile a Javascript quando pensava alla programmazione funzionale (abbi pietà di me, non mi infastidire troppo per quel confronto; -)

Joe Armstrong - "Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds."

Immagino che l'inventore di Erlang abbia delle buone argomentazioni, ma ha anche il suo punto di vista, quindi lascia che sia lui a pensare e costruisci il tuo. Ci sono molti altri esperti che hanno un'idea diversa di questo.

Ovviamente:

struct Foo
{
    string bar;
    int bux;
}

So cosa stai per dire: "Ma questo non incapsula anche il comportamento!" Beh, io sono con Joe Armstrong su questo: puoi scrivere interi programmi o sistemi operativi senza mai richiedere oggetti di prima classe. Linux lo dimostra.

I programmatori Javascript incapsulano regolarmente lo stato e il comportamento in funzioni e chiusure, non classi.

Il problema principale qui è che l'incapsulamento non è un concetto rigidamente definito né perché è utile. Fare alcune ricerche mostra che il modo in cui le persone vedono l'incapsulamento è altamente motivato e che molte persone lo confondono con l'astrazione.

Prima definizione sei andando a cercare è

Encapsulation is a concept that binds together the data and functions that manipulate the data ...

Se questa è la tua definizione, allora la maggior parte delle lingue ha modo di raggruppare dati e funzioni che operano su quei dati in classi, moduli, librerie, spazi dei nomi, ecc.

Ma direi che non è lo scopo principale dell'incapsulamento, come continua quella definizione:

... , and that keeps both safe from outside interference and misuse.

Wikipedia concorda anche su questo:

A language mechanism for restricting direct access to some of the object's components.

Ma ora, dobbiamo chiedere cosa si intende per "interferenza e uso improprio" e perché l'accesso diretto ai dati deve essere limitato. Credo che ci siano due ragioni.

Il primo è che l'ambito limitativo in cui i dati possono essere mutati è nell'interesse degli sviluppatori. Troppo spesso è necessario avere una logica prima / dopo che il valore sia impostato. E avere un numero limitato di posti in cui il valore può essere impostato è estremamente prezioso. Nei linguaggi OOP ciò può essere fatto usando le classi. Nelle chiusure linguistiche "mutabili" servono lo stesso scopo. E poiché conosciamo classes = chiusure , è persino discutibile che i linguaggi funzionali mutabili siano "paradigmi" diversi rispetto a OOP.

Ma che dire delle lingue immutabili? Non ha problemi di variabili mutanti. È qui che entra in gioco il secondo problema: le funzioni e i dati vincolanti consentono di mantenere tali dati in uno stato valido. Immagina di avere una struttura immutabile per Email . Questa struttura ha un singolo campo string . Abbiamo requisiti che se hai valore di tipo Email allora quel campo contiene un indirizzo valido. Nell'incapsulamento di OOP, questo è fatto facilmente dichiarando che il campo private , fornendo solo il metodo Get e avendo constructor method che riesce solo se passato in stringa è un indirizzo valido. Simile cosa con chiusure. Ora, per un linguaggio immutabile, avrebbe bisogno di dire che la struttura può essere inizializzata solo attraverso una funzione specifica e tale funzione può fallire. E non conosco nessun linguaggio che risponda a questi criteri (forse qualcuno nei commenti può illuminarmi)

L'ultimo numero è ciò che si intende per linguaggio che "supporta" l'incapsulamento. Da un lato ci sono linguaggi che consentono l'applicazione di incapsulamento, così che il codice non verrà compilato se l'incapsulamento è rotto. Dall'altra parte, la lingua potrebbe fornire il modo di eseguire l'incapsulamento, ma non la applica, lasciando lo sviluppatore a rafforzarla autonomamente. Per il secondo caso, qualsiasi linguaggio che abbia strutture e funzioni può funzionare. Lingue dinamiche e Haskell vengono in mente. E direi che non ci sono molte lingue che cadono dall'altra parte dello spettro. Anche C #, che è davvero bravo a far rispettare l'incapsulamento per i suoi oggetti, può essere aggirato usando la riflessione. Ma visto che in C # sarebbe considerato un enorme odore di codice e nessuno sviluppatore C # sane lo farebbe volentieri.