La programmazione orientata agli oggetti consente effetti collaterali e cambiamenti di stato?

Non esiste una definizione universale di OOP. È quindi difficile formulare una dichiarazione come "OOP ha uno stato". Esistono entrambi esempi in cui OOP include stato ed esempi in cui OOP viene utilizzato senza alcuno stato. OOP tende ad essere associato con la programmazione imperativa, che certamente consente effetti collaterali e stato mutabile.

Esiste una linea di pensiero secondo cui l'OOP riguarda l'incapsulamento. OOP non è necessario per organizzare lo stato del programma in record / strutture più piccoli. Ma se trasformiamo questi record in oggetti e incapsuliamo questi dati dietro un'interfaccia di passaggio dei messaggi, possiamo districare lo stato del programma, portando a un'architettura più disaccoppiata e modulare.

In questo modo lo stato è ancora lì, ma possiamo guardare le parti dello stato (ogni oggetto) in isolamento. Non ci saranno interferenze esterne. Se gli utenti esterni vogliono accedere o modificare lo stato, dovranno chiamare un metodo che controlliamo. Ora è più facile ragionare su un oggetto. Viceversa, gli utenti esterni devono solo conoscere l'interfaccia pubblica e non tutti i dettagli interni, il che rende anche più facile la loro vita.

Quindi si potrebbe dire che OOP è una tecnica per gestire più facilmente lo stato del programma.

L'uso di OOP per l'incapsulamento come questo si presta bene a sistemi software più grandi, almeno in teoria. Questa idea non è limitata alle istanze di singoli oggetti in un linguaggio di programmazione. Si potrebbero anche visualizzare architetture più grandi come orientate agli oggetti, ad es. in un'architettura di microservizio ogni singolo microservizio può essere interpretato come un oggetto.

Nella maggior parte dei programmi OOP-ish questa gestione dello stato non viene eseguita in modo pulito. Ogni volta che si accede a una variabile globale o si richiama una funzione statica, si sfrutta il vantaggio di disaccoppiare solo comunicando tramite chiamate di metodo. Questo tornerà a morderti se scrivi test unitari per un oggetto - qualsiasi flusso di dati attraverso membri statici è flusso di dati che non puoi intercettare, deridere e verificare.

OOP non è l'unico modo per gestire lo stato all'interno di un'applicazione più grande. Molte di queste funzionalità come "incapsulamento" sono solo un esempio del paradigma di programmazione modulare, ma non esiste una linea chiara tra programmazione modulare e orientata agli oggetti. Anziché lo stato di parcelling in blocchi più piccoli che inviano messaggi l'uno all'altro, la programmazione funzionale suggerisce di rendere tutto lo stato esplicito e immutabile. Il flusso del programma può quindi essere interpretato come trasformazioni di stato piuttosto che come mutazioni di stato.

Ecco una prospettiva un po 'eterodossa, ma (io credo), interessante.

Inizialmente, la mia opinione era che lo stato e l'identità dell'oggetto non fossero parti integranti di OO "in teoria", sebbene nella pratica siano onnipresenti. È abbastanza facile (se insolito) evitare lo stato mutabile interamente in un linguaggio OO come Java (modulo che vuole usare le librerie standard ...) Ad esempio, Abadi e Cardelli hanno entrambe le versioni mutevoli e immutabili del loro ς-calculus che doveva essere per OO quello che il calcolo λ è per FP. Basti dire che né esso né alcun altro "calcolo degli oggetti" sono riusciti a rivendicare un tale ruolo.

C'è fondamentalmente solo un altro "calcolo" che ha acquisito un significato anche avvicinandosi al calcolo λ e questo è il di Milner calcolo π che è stato progettato per il ragionamento su sistemi concorrenti. Le mie opinioni sono cambiate dopo aver scritto una discreta quantità di codice in uno stile di calcolo π, e in particolare quando ho scoperto i calcoli blu e blu scuro che osservano che il codice scritto nel calcolo π tende a sembrare e a lavorare nello stile di passaggio continuo e cerca di fornire una variazione di "stile diretto" del calcolo π. Il risultato è piuttosto come un linguaggio OO concorrente (e uno che può catturare senza intoppi il calcolo ς non meno). Allo stesso modo, anche la scrittura di codice nel calcolo π tende a produrre pattern che ricordano molto gli oggetti in stile OO.

Questa prospettiva fornisce una base sicura per molti, ma non tutti, aspetti dei linguaggi OO e la concorrenza e OO sono stati correlati in una varietà di modi (modello attore, oggetti attivi, simulazioni di eventi discreti di Simula, passaggio di messaggi) in tutta la storia di OO. Naturalmente, la maggior parte dei moderni linguaggi OO non enfatizza la concorrenza. In effetti, la visione di OO in questa prospettiva suggerisce molto più come Erlang che Java. Tuttavia, questa prospettiva implica che lo stato mutabile e l'identità dell'oggetto sono intrinseci. Mentre all'interno di un "processo" potremmo non avere uno stato mutabile, come in Erlang dove il corpo di ogni processo è (principalmente) puramente funzionale, è banale modellare lo stato mutabile come un processo. Allo stesso modo, mentre il calcolo π non ha nulla come l'uguaglianza di riferimento e non è banale modellarlo, è comunque chiaro che due processi sono distinti anche se hanno la stessa identica definizione. (In termini Erlang / attore, hanno "caselle di posta" differenti.)

Credo che Object-Oriented consenta effetti collaterali e cambiamenti di stato, ma i sistemi oggetto ben progettati lo fanno in una bolla relativamente piccola e ben delimitata alla volta. Le piattaforme basate su attore sono un buon esempio di questo principio seguito rigorosamente.

Se guardi al racconto di Alan Kay degli inizi di Smalltalk (il linguaggio che ha introdotto il termine orientato agli oggetti ) e ai primi linguaggi OO, se cambiare o meno lo stato strong> non sembra nemmeno essere una domanda allora. Era implicito che qualcosa doveva essere modificabile per far funzionare un sistema, ma ciò che veramente importava era come e se l'oggetto chiamante doveva essere a conoscenza di qualsiasi di esso . Vale a dire, la grande idea era che gli oggetti avevano una memoria interna, una che non poteva essere modificata dall'esterno con assegnazioni dirette e fini, ma poteva essere passata solo chiamando metodi che riflettevano i comportamenti di livello superiore dell'oggetto.