I paradigmi non OOP supportano concetti come l'incapsulamento?

Uno dei concetti importanti nella programmazione orientata agli oggetti è l'incapsulamento. Tuttavia, ultimamente il mondo del software sembra inclinarsi a favore di altri paradigmi come la programmazione funzionale.

Mi fa pensare, che dire dell'incapsulamento e di altri principi OOP? Si sbagliano?

OOP è applicato in modo errato? Ad esempio, Alan Kay è noto per aver detto nel Keynote di OOPSLA'97: "Ho inventato il termine orientato agli oggetti e posso dire che non avevo in mente C ++".

Joe Armstrong - "Gli oggetti associano funzioni e strutture di dati in unità indivisibili. Penso che questo sia un errore fondamentale poiché funzioni e strutture di dati appartengono a mondi totalmente diversi."

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

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

Tuttavia , nel mondo reale, le cose non sono così nette, motivo per cui due sviluppatori daranno due risposte diverse. Forse sono esperti in diverse lingue che esprimono i concetti di OOP in modo diverso. I paradigmi linguistici tendono a sovrapporsi. L'ultima rabbia 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 definirei orientato agli oggetti con un pizzico di funzionale. Qualcun altro potrebbe descriverlo in modo diverso.

OOP è applicato in modo errato?

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

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

Tuttavia, ultimamente il mondo del software sembra inclinarsi a favore di altri paradigmi come la programmazione funzionale.

È discutibile. In primo luogo, non vedo altri paradigmi oltre a OOP e la programmazione funzionale che sono discussi in modo ampio, quindi immagino che possiamo dimenticare la frase "altri paradigmi come" , parliamo di FP, nient'altro.

I motivi per cui la programmazione funzionale è diventata così popolare negli ultimi anni sono stati discussi in altre domande qui in profondità, non ho intenzione di ripeterlo (vedi qui o qui , per esempio). Ma, secondo me, ciò non è dovuto al fatto che "OOP è stato un grosso errore", o "Funzionale contro OOP si escludono a vicenda", è più come se le persone estendessero la loro cassetta degli attrezzi e cercassero di ottenere il meglio da entrambi i mondi. Ok, ci sono sicuramente esperti che sono sostenitori della linea dura che favoriscono l'uno sull'altro, ma troverai quei ragazzi da entrambe le parti.

Mi fa pensare, che dire dell'incapsulamento e di altri principi OOP? Si sbagliano?

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

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

OOP è applicato in modo errato? Ad esempio, Alan Kay è noto per aver detto nel Keynote di OOPSLA'97: "Ho inventato il termine orientato agli oggetti e posso dire che non avevo in mente C ++".

Sicuramente OOP viene spesso applicato in modo errato da molte persone, ma sono sicuro che lo stesso vale per FP. E sarei sorpreso se John Mc Carthy (designer di Lisp) avesse in mente qualcosa come Javascript quando pensava alla programmazione funzionale (pietà di me, non farmi troppo fuoco per quel confronto ;-)

Joe Armstrong - "Gli oggetti associano funzioni e strutture di dati in unità indivisibili. Penso che questo sia un errore fondamentale poiché funzioni e strutture di dati appartengono a mondi totalmente diversi."

Immagino che l'inventore di Erlang abbia delle buone argomentazioni, ma ha anche il suo punto di vista personale, quindi lasciagli la sua opinione e costruisci la tua. Ci sono molti altri esperti che hanno un'idea diversa di questo.

Ovviamente:

struct Foo
{
    string bar;
    int bux;
}

So cosa dirai: "Ma questo non incapsula anche il comportamento!" Bene, sto con Joe Armstrong su questo: puoi scrivere interi programmi o sistemi operativi senza mai aver bisogno di oggetti di prima classe. Linux lo dimostra.

I programmatori Javascript incapsulano abitualmente lo stato e il comportamento in funzioni e chiusure, non in 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 supponente e che molte persone lo confondono con l'Astrazione.

La prima definizione che troverai è

L'incapsulamento è un concetto che unisce i dati e le funzioni che manipolano i dati ...

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

Ma direi che non è lo scopo principale dell'incapsulamento, poiché tale definizione continua:

... e ciò protegge sia da interferenze esterne che da abusi.

Wikipedia è anche d'accordo sul fatto che:

Un meccanismo linguistico per limitare l'accesso diretto ad alcuni dei componenti dell'oggetto.

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

Il primo è che l'ambito di limitazione in cui i dati possono essere mutati è nel miglior interesse dello sviluppatore. Troppo spesso è necessario impostare la logica prima / dopo l'impostazione del valore. E avere un numero limitato di posti in cui è possibile impostare il valore è estremamente prezioso. Nei linguaggi OOP questo può essere fatto usando le classi. In linguaggi funzionali "mutabili" le chiusure hanno lo stesso scopo. E poiché conosciamo le classi = chiusure , è persino discutibile che i linguaggi funzionali mutabili siano diversi "paradigmi" rispetto a OOP.

Ma che dire delle lingue immutabili? Non ha problemi di mutare le variabili. È qui che entra in gioco il secondo problema: funzioni e dati di associazione consentono di mantenere tali dati in uno stato valido. Immagina di avere una struttura immutabile per Email. Questa struttura ha un stringcampo singolo . Abbiamo requisiti che se si dispone di un valore di tipo, Emailquel campo contiene un indirizzo valido. Nell'incapsulamento di OOP, questo viene fatto facilmente dichiarando quel campo private, fornendo solo Getmetodo e avendoconstructor methodche ha successo solo se passato in stringa è un indirizzo valido. Cosa simile con le chiusure. Ora, per un linguaggio immutabile, sarebbe necessario dire che la struttura può essere inizializzata solo attraverso una funzione specifica e tale funzione può fallire. E non sono a conoscenza di alcuna lingua che si adatti a quei criteri (forse qualcuno nei commenti può illuminarmi).

L'ultimo problema è ciò che si intende per incapsulamento "di supporto" del linguaggio. Da un lato ci sono lingue che consentono l'applicazione dell'incapsulamento, in modo che il codice non si compili se l'incapsulamento è rotto. D'altra parte, il linguaggio potrebbe fornire il modo di fare l'incapsulamento, ma non lo impone, lasciando che lo sviluppatore lo imponga da solo. Nel secondo caso, qualsiasi linguaggio che abbia strutture e funzioni può funzionare. Vengono in mente linguaggi dinamici e Haskell. E direi che non ci sono molte lingue che ricadono 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 odore massiccio di codice e nessuno sviluppatore C # sano lo farebbe volentieri.