Possiamo dire che gli oggetti hanno attributi, stati e comportamenti?

Stavo leggendo l'introduzione di Oracle ai concetti di OOP e mi sono imbattuto in questa descrizione:

Gli oggetti del mondo reale condividono due caratteristiche: hanno tutti stato e comportamento. I cani hanno stato (nome, colore, razza, fame) e comportamento (abbaiare, andare a prendere, scodinzolare). Gli oggetti software sono concettualmente simili agli oggetti del mondo reale: anch'essi sono costituiti da stato e comportamento correlato.

Il mio problema con quel passaggio è che quando descrive lo stato mescola anche lì gli attributi . Ad esempio, il nome e il colore di un cane sono i suoi attributi, mentre essere affamato o malizioso sono i suoi stati.

Quindi secondo me è più accurato suddividere le caratteristiche degli oggetti in tre parti: attributi, stati e comportamenti .

Certo, quando traduco questo in un linguaggio di programmazione, vedo che la partizione tripla diventa duplice, perché sia ​​gli attributi che gli stati verranno memorizzati in campi / variabili, mentre i comportamenti verranno archiviati in metodi / funzioni.

Ma concettualmente parlando ha più senso separare le 3 cose.

Ecco un altro esempio: considera una lampada. Dire che sia la dimensione della lampada sia l'accensione o meno sono degli stati è secondo me un allungamento. La dimensione della lampada è un attributo, non uno stato, mentre l'accensione o lo spegnimento è uno stato.

O mi sono perso qualcosa?

Hai ragione nel dire che gli oggetti sono costituiti da attributi, stati e comportamenti, se definisci attributi per indicare caratteristiche non mutevoli di un'istanza. È un dato di fatto, è importante fare questa distinzione, perché esistono oggetti che contengono solo attributi, (nel tuo senso), e nessuno stato; sono chiamati immutabili e sono molto utili nella programmazione.

Questa definizione in tre parti è effettivamente rappresentata nei linguaggi di programmazione, ad esempio utilizzando la finalparola chiave in Java o la readonlyparola chiave in C # per indicare i dati dell'istanza che potrebbero non cambiare durante il ciclo di vita dell'istanza.

Devo aggiungere, tuttavia, che i dati delle istanze non modificabili di solito non vengono chiamati attributi. Tendiamo a parlarne come 'finali' o 'di sola lettura' o 'dati costanti' a seconda della lingua che stiamo usando. Il termine appropriato per loro sarebbe "invarianti", ma allora questa parola non viene frequentemente usata in questo senso; è più spesso usato per altre cose.

Penso che sia più preciso dire che gli oggetti hanno solo due caratteristiche. Prendendo l'esempio di Oracle:

I cani hanno stato (nome, colore, razza, fame) e comportamento (abbaiare, andare a prendere, scodinzolare). Gli oggetti software sono concettualmente simili agli oggetti del mondo reale: anch'essi sono costituiti da stato e comportamento correlato.

Il fatto che i valori (stato) per nome, colore, razza e fame siano memorizzati nell'oggetto negli attributi è un dettaglio di implementazione. Non hai davvero bisogno di attributi.

Se includerai gli attributi come terza caratteristica, dovresti anche includere i metodi come quarta, poiché anche i comportamenti (come lo stato) degli oggetti possono cambiare. Stato e comportamento sono due caratteristiche astratte degli oggetti. Attributi e metodi sono implementazioni concrete di tali concetti.

State è un insieme di attributi e valori corrispondenti, quindi dal mio punto di vista, non hai ragione (e stai creando una complessità aggiuntiva non necessaria alla semplice definizione).

Possiamo classificare le cose in innumerevoli modi e ogni classificazione non avrebbe una "risposta giusta". La classificazione delle cose ha un vantaggio solo se la classificazione porta a una comprensione più profonda o a migliorare la comunicazione. Se il tuo team preferisce utilizzare i termini attributi, stati e funzioni e ha buone definizioni di lavoro per questi, ciò contribuirà a migliorare la comunicazione interna ma devi essere flessibile quando comunichi al di fuori di questo gruppo.

I concetti "fame" e "sete" possono essere derivati ​​da attributi di base (ad es. Glicemia, livello di idratazione) in modo da poter pensare allo stato come un meta-attributo che deriva da attributi di base che possiamo passare a Vero o Falso in base a lo stato degli attributi di base pertinenti. Per l'esempio luce, si potrebbe pensare alla luce come aventi le caratteristiche applied_voltagee resistancee le funzioni voltage_switch()e shine(). La voltage_swich()è quindi una funzione di alcuni input (es interruttore manuale, luce, timer, etc.) ed shine()è una funzione di applied_voltagee resistance. Potremmo dichiarare un meta-attributo chiamato light_stateTrue o False per aiutare a costruire mentalmente l'oggetto, ma alla fine queste idee sono solo costrutti mentali che usiamo per organizzare il nostro lavoro.

Lo stato di un oggetto è codificato nei suoi attributi, direttamente o indirettamente. Ad esempio, se vuoi che il tuo cane abbia sete, puoi lasciarlo avere

private boolean thirsty;

In alternativa, puoi lasciare che abbia qualcosa di simile

private Date lastDrinkAt;

e concludi se la tua istanza di cane ha sete confrontando l'ora corrente con l'ultima volta che ha bevuto qualcosa.

In entrambi i casi, lo stato dei tuoi oggetti si trova nei suoi attributi.

Quindi ci sono classi che non hanno attributi, principalmente classi di utilità. Ma di solito non vuoi crearne nemmeno un'istanza in questo caso.

Per poter ragionare sulle affermazioni, gli scienziati di solito si attengono al principio della minimalità. Penso che sia per questo che Oracle non ha menzionato esplicitamente lo stato. Può essere derivato dal valore degli attributi.

Le connessioni del mondo reale sono sbagliate. Ecco come lo insegnerei (approccio c ++):

1. I computer supportano due diversi formati di archiviazione: dati e codice
2. i dati assomigliano ai bit 010101010101
3. il codice appare come istruzioni asm
4. i bit di dati hanno due valori diversi, 0 o 1
5. i dati sono astratti in tipi di dati: int i = 1; è solo una breve notazione per alcuni bit 0000001
6. il codice apparirà come una funzione: int f (int a) {return a + a + a; } è una breve notazione per alcune istruzioni asm
7. quando hai diverse variabili, le combini in una struttura: int a; galleggiante b; può essere posizionato in una struttura AB {int a; galleggiante b; };
8. quando si combinano alcuni pezzi di codice, si ottiene una classe: class ABf {int a; galleggiante b; somma float (float c) const {return a + b + c; }};
9. Quindi per i dati abbiamo nomi di variabili che possono essere usati per trovare il valore: a + b + c per accedere ai dati.
10. E poi abbiamo le normali chiamate di funzione: int k = f (10); per accedere alle istruzioni asm "memorizzate" all'interno della funzione f.
11. Quindi ci sono istanze di oggetto: ABf var;
12. E la funzione membro chiama: int k2 = var.sum (10.0);
13. le funzioni hanno tipi int f (int);
14. le funzioni membro hanno tipi int ABf :: sum (float);
15. C'è questo puntatore con tipo ABf *
16. variabili come a e b e c dipendono dal contesto, se sono all'interno della funzione membro, potrebbero significare questo-> b, o semplicemente b.
17. Funzioni membro int ABf :: sum (float c) è solo una breve notazione per int sum (ABf * this, float c);
18. la parola "stato" significa solo i dati
19. la parola "comportamento" significa semplicemente lo stesso codice
20. la parola "attributo" significa solo i dati.

Quindi non c'è davvero nulla di diverso tra stato e attributo. È solo una raccolta casuale di bit. È solo una distinzione arbitraria per separarli. Devo solo sapere a cosa serve.