Il termine " stato " può essere usato in vari sensi, il che potrebbe non essere neppure suscettibile di una definizione precisa. Era quindi importante che tu includessi una definizione nel tuo documento, per chiarire come stavi usando il termine. Di seguito non offro una definizione univoca dello stato di un oggetto, ma piuttosto provo a delineare una serie di modi di pensarlo, che possono essere appropriati in contesti diversi.
Per prima cosa, tuttavia, devi pensare a cosa intendi per " oggetto ": stai pensando a un oggetto concettuale, ad esempio un'entità che stai cercando di modellare o a un'istanza di una classe in un programma specifico; forse vuoi anche pensare allo stato di una variabile che potrebbe, in momenti diversi, riferirsi a oggetti diversi o a un sistema, magari accessibile tramite una certa interfaccia utente.
Parte della difficoltà nel definire lo stato di un oggetto in OOP è che quando modelliamo entità in un particolare linguaggio, quel linguaggio spesso non ci permette di distinguere gli attributi dell'oggetto che sono concettualmente parte della stessa entità da altri che non lo sono. Ad esempio, un elenco collegato Carsarà costituito da un numero di Linkoggetti, che contengono puntatori al successivo (e forse precedente) Linksebbene concettualmente l'elenco sia un singolo oggetto; i collegamenti possono anche essere incorporati inCar-oggetto o contiene puntatori ad essi, ma in questo caso gli oggetti collegati sono concettualmente separati piuttosto che parte dell'elenco; in un elenco di modifiche recenti, tuttavia, le modifiche possono essere presenti nell'elenco e considerate come parte di esso. In questi vari casi dobbiamo decidere se consideriamo lo stato di un oggetto per includere quello degli oggetti collegati. Inoltre, a Carpotrebbe avere un collegamento a un Registering_Authority- probabilmente non consideriamo lo stato della macchina cambiare quando la sua autorità di registrazione cambia l'URL del suo sito Web. A meno che il linguaggio di implementazione non ci consenta di distinguere diversi tipi di collegamento, non sarà possibile fare una definizione generale dello stato di un oggetto in termini di solo linguaggio.
Il ' esterna ' o ' funzionale ' stato potrebbe essere definito come 'come si comporta', ee.g. come reagisce alle invocazioni del metodo o all'interfaccia utente. Per un oggetto come istanza di classe questa definizione dipende dal tipo a cui l'oggetto è visto come appartenente: visto come a Circle, il colore di unColoured_Circlenon è visibile, e quindi irrilevante per il suo stato. Una difficoltà in questo è che potrebbe essere necessario definire "come reagisce" in termini di valori restituiti e questi "valori" potrebbero essere gli stati di altri oggetti. Un modo per formalizzare ciò è quello di dire che due stati di un oggetto sono uguali se tutte le possibili esecuzioni future di un sistema in cui è incorporato comportano la stessa mappatura dagli input a quel sistema agli output da esso. È possibile che questo sistema di chiusura sia un sistema autonomo, in grado di essere eseguito indipendentemente dal suo ambiente; d'altra parte, si potrebbe consentire che sia piccolo quanto l'oggetto in questione stesso. In ogni caso, un approccio matematico consiste nel definire uno stato come una classe di equivalenza di
Il ' interno ' stato potrebbe essere definito come lo stato della rappresentazione. Un primo tentativo è apparentemente circolare ma forse utile: "Lo stato interno di un oggetto è lo stato dei suoi membri". Qui dobbiamo fare attenzione a distinguere gli aspetti significativi della rappresentazione da quelli insignificanti: al livello più basso, la rappresentazione di un oggetto può ben includere indirizzi di altri oggetti, ma è improbabile che sia utile considerare un cambiamento in tale indirizzo come un cambiamento di stato. D'altra parte, una modifica dello stato di una cache per il risultato di una query, sebbene non faccia alcuna differenza per lo stato funzionale (come descritto sopra), sarà importante quando si considerano i test delle prestazioni.