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

Hai ragione nel fatto che gli oggetti consistono di attributi, stati e comportamenti, se definisci attributi che intendono caratteristiche non mutevoli di un'istanza. In effetti, è importante fare questa distinzione, perché esistono oggetti che contengono attributi solo , (nel senso tuo) e nessuno stato; sono chiamati immutable e sono molto utili nella programmazione.

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

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

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

Dogs have state (name, color, breed, hungry) and behavior (barking, fetching, wagging tail). Software objects are conceptually similar to real-world objects: they too consist of state and related behavior.

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

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

Lo stato è 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 definizione semplice).

Possiamo classificare le cose in innumerevoli modi e ogni classificazione non avrebbe una "risposta giusta". C'è un vantaggio nel classificare le cose solo se la classificazione porta a una comprensione più profonda oa migliorare la comunicazione. Se la tua squadra preferisce usare i termini attributi, stati e funzioni e ha delle buone definizioni di lavoro per questi, questo aiuterà a migliorare la comunicazione interna, ma devi essere flessibile quando comunichi al di fuori di questo gruppo.

I concetti "affamato" e "assetato" possono essere derivati da attributi di base (ad es. glicemia, livello di idratazione) in modo che potremmo pensare allo stato come a un meta-attributo derivato da attributi di base che possiamo passare a True o a Falso in base allo stato degli attributi di base pertinenti. Per l'esempio di luce, potremmo pensare che la luce abbia gli attributi applied_voltage e resistance e le funzioni voltage_switch() e shine() . Il voltage_swich() è quindi una funzione di qualche input (ad es. Switch manuale, luce, timer, ecc.) E shine() è una funzione di applied_voltage e resistance . Potremmo dichiarare un meta-attributo chiamato light_state che è Vero o Falso per aiutare a costruire mentalmente l'oggetto, ma alla fine queste idee sono tutte 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 un

private boolean thirsty;

In alternativa, puoi lasciarlo avere qualcosa di simile a

private Date lastDrinkAt;

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

In entrambi i casi, lo stato dei tuoi oggetti si trova all'interno dei suoi attributi.

Poi ci sono classi che non hanno attributi, per lo più classi di utilità. Ma di solito non vuoi creare 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 lo stato in modo esplicito. Può essere derivato dal valore degli attributi.

Le connessioni nel mondo reale sono fuorviate. Ecco come vorrei insegnarlo (approccio c ++):

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

Quindi non c'è davvero nulla di diverso tra stato e attributo. È solo una raccolta casuale di bit. È solo una distinzione arbitraria per separarli. Ho solo bisogno di sapere per cosa è l'alias.