Podemos dizer que os objetos têm atributos, estados e comportamentos?

Eu estava lendo a introdução da Oracle aos conceitos de OOP e me deparei com esta descrição:

Objetos do mundo real compartilham duas características: Todos eles têm estado e comportamento. Os cães têm estado (nome, cor, raça, fome) e comportamento (latir, buscar, abanar a cauda). Objetos de software são conceitualmente semelhantes aos objetos do mundo real: eles também consistem em estado e comportamento relacionado.

Meu problema com essa passagem é que, ao descrever o estado, suas misturas também são atribuídas lá. Por exemplo, o nome e a cor de um cão são os seus atributos, enquanto que a fome ou o excesso de gordura são os seus estados.

Então, na minha opinião, é mais preciso quebrar as características dos objetos em três partes: atributos, estados e comportamentos .

Certamente, ao traduzir isso para uma linguagem de programação, posso ver que a partição tripla se torna dupla, porque atributos e estados serão armazenados em campos / variáveis, enquanto comportamentos serão armazenados em métodos / funções.

Mas, conceitualmente, faz mais sentido separar as três coisas.

Aqui está outro exemplo: considere uma lâmpada. Dizer que o tamanho da lâmpada e se está ligado ou não são estados é um exagero na minha opinião. O tamanho da lâmpada é um atributo, não um estado, enquanto ligado ou desligado é um estado.

Ou eu perdi alguma coisa?

Você tem razão em que os objetos consistem em atributos, estados e comportamento, se você definir atributos para significar características não alteráveis ​​de uma instância. De fato, é importante fazer essa distinção, porque existem objetos que contêm apenas atributos (no seu sentido) e nenhum estado; eles são chamados imutáveis e são muito úteis em programação.

Essa definição em três partes é realmente representada nas linguagens de programação, por exemplo, usando a finalpalavra - chave em Java ou a readonlypalavra - chave em C # para indicar dados da instância que podem não mudar durante o tempo de vida da instância.

Tenho que acrescentar, no entanto, que os dados da instância não alteráveis ​​geralmente não são chamados de atributos. Nós tendemos a falar deles como 'finais' ou 'somente leitura' ou 'dados constantes', dependendo do idioma que estamos usando. O termo adequado para eles seria 'invariantes', mas essa palavra não é usada com frequência nesse sentido; é mais frequentemente usado para outras coisas.

Eu acho que é mais preciso dizer que os objetos têm apenas duas características. Tomando o exemplo da Oracle:

Os cães têm estado (nome, cor, raça, fome) e comportamento (latir, buscar, abanar a cauda). Objetos de software são conceitualmente semelhantes aos objetos do mundo real: eles também consistem em estado e comportamento relacionado.

O fato de os valores (estado) de nome, cor, raça e fome serem armazenados no objeto em atributos é um detalhe de implementação. Você realmente não precisa de atributos.

Se você incluir atributos como uma terceira característica, também precisará incluir métodos como uma quarta, pois os comportamentos dos objetos (como o estado) também podem mudar. Estado e comportamento são duas características abstratas dos objetos. Atributos e métodos são implementações concretas desses conceitos.

Estado é um conjunto de atributos e valores correspondentes, portanto, do meu ponto de vista, você não está certo (e está criando complexidade adicional desnecessária para uma definição simples).

Podemos classificar as coisas de inúmeras maneiras e cada classificação não teria "resposta certa". Há um benefício em classificar as coisas somente se a classificação levar a um entendimento mais profundo ou a melhorar a comunicação. Se sua equipe preferir usar os termos atributos, estados e funções e tiver boas definições de trabalho para isso, isso ajudará a melhorar a comunicação interna, mas você precisará ser flexível ao se comunicar fora deste grupo.

Os conceitos "com fome" e "com sede" podem ser derivados de atributos básicos (por exemplo, glicose no sangue, nível de hidratação), para que pudéssemos pensar no estado como um meta-atributo derivado dos atributos básicos que podemos alternar para Verdadeiro ou Falso, com base em o estado dos atributos base relevantes. Para o exemplo luz, poderíamos pensar na luz como tendo os atributos applied_voltagee resistancee as funções voltage_switch()e shine(). A voltage_swich()é então uma função de alguma entrada (por exemplo, interruptor manual, a luz, o temporizador, etc.) e shine()é uma função da applied_voltagee resistance. Poderíamos declarar um meta-atributo chamado light_stateVerdadeiro ou Falso para ajudar a construir mentalmente o objeto, mas no final essas idéias são apenas construções mentais que usamos para organizar nosso trabalho.

O estado de um objeto é codificado em seus atributos, direta ou indiretamente. Por exemplo, se você deseja que seu cão tenha sede, pode deixá-lo

private boolean thirsty;

Como alternativa, você pode deixar algo como

private Date lastDrinkAt;

e conclua se sua instância de cachorro está com sede comparando a hora atual com a última vez que bebeu alguma coisa.

De qualquer forma, o estado dos seus objetos está dentro dos seus atributos.

Depois, existem classes que não têm atributos, principalmente classes de utilidade. Mas você geralmente não deseja criar uma instância deles também neste caso.

Por uma questão de ser capaz de raciocinar sobre declarações, os cientistas geralmente aderem ao princípio da minimalidade. Eu acho que é por isso que a Oracle não mencionou estado explicitamente. Pode ser derivado do valor dos atributos.

As conexões do mundo real são equivocadas. Aqui está como eu o ensinaria (abordagem c ++):

1. Os computadores suportam dois formatos diferentes de armazenamento: dados e código
2. dados parecem bits 010101010101
3. código parece instruções ASM
4. bits de dados têm dois valores diferentes, é 0 ou 1
5. dados são abstraídos para tipos de dados: int i = 1; é apenas uma notação curta para alguns bits 0000001
6. código terá a aparência de uma função: int f (int a) {retorna a + a + a; } é uma notação curta para algumas instruções asm
7. quando você tem várias variáveis, você as combina em uma estrutura: int a; flutuador b; pode ser colocado em uma estrutura AB {int a; flutuador b; };
8. quando você combina algumas partes do código, obtém uma classe: class ABf {int a; flutuador b; soma flutuante (flutuante c) const {retorna a + b + c; }};
9. Então, para dados, temos nomes de variáveis ​​que podem ser usados ​​para encontrar o valor: a + b + c para acessar os dados.
10. E então temos chamadas de função normais: int k = f (10); para acessar as instruções asm "armazenadas" dentro da função f.
11. Depois, há instâncias de objeto: ABf var;
12. E a função membro chama: int k2 = var.sum (10.0);
13. funções têm tipos int f (int);
14. funções-membro possuem tipos int ABf :: sum (float);
15. Existe este ponteiro com o tipo ABf *
16. variáveis ​​como a e bec dependem do contexto; se estiverem dentro da função de membro, elas podem significar isso-> b ou apenas b.
17. As funções-membro int ABf :: sum (float c) são apenas uma notação curta para int sum (ABf * this, float c);
18. a palavra "estado" significa apenas o mesmo que dados
19. a palavra "comportamento" significa apenas o mesmo que código
20. a palavra "atributo" significa apenas o mesmo que dados.

Portanto, não há realmente nada diferente entre estado e atributo. É apenas uma coleção aleatória de bits. É apenas uma distinção arbitrária para separá-los. Só preciso saber para que serve o alias.