Cosa si intende per "OOP nasconde lo stato"? [chiuso]

What exactly is meant by this?

In questo contesto, significa che OOP oscura lo stato di un programma nascondendolo lontano dal programmatore ma rendendolo comunque visibile tramite metodi di accesso (leaky). L'argomento è che oscurando lo stato, rende più difficile lavorare con, e per estensione portare a più bug.

how accurate/relevant do you guys think that passage is?

Ritengo che sia pertinente, ma indirizzato male. C'è assolutamente un problema se la tua classe perde il concetto del suo stato nel mondo esterno. C'è assolutamente un problema se la tua classe cerca di oscurare lo stato quando dovrebbe essere manipolato dal mondo esterno. Questo però non è un fallimento dell'OOP nel suo complesso, ma con il design individuale della classe. Non direi che lo stesso stato nascosto è un problema - le monadi lo fanno sempre nella programmazione funzionale.

Nel migliore dei casi, OOP funziona come il miglior mix di programmazione funzionale e procedurale - le persone possono usare la classe "come se lo stato non avesse importanza" perché lo stato privato usato per proteggere gli invarianti della classe è nascosto, ma avere la libertà di usare uno stato pubblico ben definito della classe che astrae i dettagli.

OOP rende più difficile per le persone ottenere il meglio dei casi? Possibilmente. "Le scuole Java" e l'intero Shape / Circle / Rectangle o Car hanno la scuola di Wheels nell'insegnamento OO probabilmente hanno più da biasimare rispetto all'approccio stesso. Modern OOP prende molto dalla programmazione funzionale, incoraggiando oggetti immutabili e funzioni pure, scoraggiando l'ereditarietà per rendere più facile la progettazione di classi che funzionano bene.

Ragionare su un sistema sarà difficile se ci sono pezzi di stato mutabile che non hanno un singolo "proprietario" chiaro. Ciò non significa che gli oggetti non dovrebbero mai avere uno stato mutabile, ma piuttosto che gli oggetti che hanno uno stato mutevole non dovrebbero essere usati in modi in cui la proprietà potrebbe non essere chiara, e viceversa che gli oggetti che devono essere liberamente passati senza tenere traccia della proprietà dovrebbero essere immutabile.

In pratica, una programmazione efficiente spesso richiede che alcuni oggetti abbiano uno stato mutabile; tale stato, tuttavia, dovrebbe essere limitato, tuttavia, agli oggetti di lavoro non condivisi . Considera le interfacce IEnumerable / IEnumerator in .NET: se una raccolta implementa IEnumerable , consentirà la lettura degli articoli uno alla volta. L'effettivo processo di lettura di una raccolta richiederà spesso di tenere traccia di quali elementi sono stati letti (uno stato mutevole), ma tale stato non è contenuto in un'implementazione di IEnumerable . Invece, IEnumerable fornisce un metodo chiamato GetEnumerator che restituirà un oggetto che implementa IEnumerator e contiene uno stato sufficiente per consentire la lettura degli elementi dalla raccolta. Il fatto che l'oggetto contenga tale stato non pone problemi, tuttavia, se l'oggetto che implementa IEnumerator non è condiviso .

Il modello migliore nella maggior parte dei casi è usare una miscela di oggetti che sono liberamente condivisi ma che non saranno mai modificati (almeno non dopo che sono stati condivisi) e oggetti che hanno un chiaro proprietario e possono essere liberamente modificati da quel proprietario, ma non sono mai condivisi con nessuno.

A rischio di andare oltre la domanda, è facile vedere difetti nell'idea di OOP, ma sono incline a pensare che il potere di un'idea si riflette nella sua capacità di essere abusato.

Dopo tutto, ognuno ha la sua lingua preferita, che descrive in termini come "molto molto potenti", il che significa che mi piace veramente . Ma la meraviglia dell'universalità computazionale è che non importa quanto sia glorioso un linguaggio, se è veramente potente può simulare il linguaggio dell'assemblaggio. E se può, qualcuno lo vedrà. (Non che ci sia qualcosa di sbagliato nel linguaggio assembly.)

Il mio personale sentimento sul carrozzone OOP è che rappresenta un ostacolo all'istruzione delle persone nell'ingegneria del software / informatica. Sono rachitici a un livello in cui pensano che sia tutto incentrato sulla struttura dei dati. Classi, ereditarietà, contenitori, iteratori, mappe di hash, proprietà, nascondigli di stato , ecc. - tutto sulla struttura dei dati - più siamo meglio è.

Personalmente mi piacerebbe vedere un livello successivo in cui le persone imparerebbero a risolvere i problemi osservandoli linguisticamente. Dove capirebbero il concetto di linguaggi specifici del dominio, come renderli facilmente e lasciare che la loro creazione sia parte integrante della risoluzione dei problemi. Non è sbagliato dire che una struttura dati è una lingua. Le persone dovrebbero avere quell'abilità nella progettazione del linguaggio, quindi non lo stanno solo borbottando.

Quindi, come livello successivo, mi piacerebbe vedere l'intelligenza artificiale rinvigorita. Mi piacerebbe vedere i programmatori andare oltre i byte e i thread e le tabelle delle funzioni virtuali e CUDA e passare a come far sì che le macchine ragionino, imparino e creino. So che questo è avanzato molto lontano in piccoli angoli del campo, ma in nessun posto abbastanza largo.

L'accessibilità non è una funzionalità di OOP, è specifica per implementazioni come Java e Microsoft dotNET. La caratteristica principale che definisce OOP è il polimorfismo.

Ad ogni modo, nascondendo lo stato dell'oggetto, non c'è modo di creare un'API significativa. La presentazione è una componente vitale dell'OOP del mondo reale. Coloro che non sono d'accordo probabilmente hanno un'irrazionale ostilità nei confronti dell'industria del software, il che rende la loro opinione irrilevante dal mio punto di vista.

Siti web come quello che hai collegato sono noti per pensieri e critiche estremamente rigide sulle nuove tecnologie. Alcune persone semplicemente non capiscono.