Podemos dizer que os objetos possuem atributos, estados e comportamentos?

15

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

Real-world objects share two characteristics: They all have state and behavior. 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.

Meu problema com essa passagem é que ao descrever state suas misturas atributos também. Por exemplo, o nome e a cor de um cachorro são seus atributos, enquanto que estar com fome ou com sede são seus estados.

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

Claro, ao traduzir isso em uma linguagem de programação, posso ver que a partição de três dobras se torna duas vezes, porque os atributos e estados serão armazenados em campos / variáveis, enquanto os comportamentos serão armazenados em métodos / funções .

Mas conceitualmente falando, faz mais sentido ter as 3 coisas separadas.

Aqui está outro exemplo: considere uma lâmpada. Dizer que o tamanho da lâmpada e se ela está ou não ligada são estados é uma extensão na minha opinião. O tamanho da lâmpada é um atributo, não um estado, enquanto ser ativado ou desativado é um estado.

Ou eu perdi alguma coisa?

    
por Daniel Scocco 05.01.2012 / 17:37
fonte

6 respostas

13

Você está certo em que os objetos consistem em atributos, estados e comportamento, se você definir atributos como significando 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 (em seu sentido) e nenhum estado; eles são chamados imutáveis e são muito úteis na programação.

Essa definição de três partes é de fato representada em linguagens de programação, por exemplo, usando a palavra-chave final em Java ou a palavra-chave readonly em C # para indicar dados da instância que podem não mudar durante a vida útil da instância.

Eu tenho que adicionar, no entanto, que os dados da instância que não mudam geralmente não são chamados de atributos. Nós tendemos a falar deles como 'final' ou 'somente leitura' ou 'dados constantes', dependendo da linguagem que estamos usando. O termo apropriado para eles seria "invariantes", mas então essa palavra não é usada com frequência nesse sentido; é mais usado para outras coisas.

    
por 05.01.2012 / 18:05
fonte
4

Acho mais correto dizer que os objetos têm apenas duas características. Tomando o exemplo da 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.

O fato de os valores (estado) para 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ê vai incluir atributos como uma terceira característica, então você também deve incluir métodos como um quarto, já que (como o estado) os comportamentos dos objetos podem mudar também. Estado e comportamento são duas características abstratas dos objetos. Atributos e métodos são implementações concretas desses conceitos.

    
por 05.01.2012 / 18:38
fonte
1

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

    
por 05.01.2012 / 17:42
fonte
0

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 apenas se a classificação levar a um entendimento mais profundo ou melhorar a comunicação. Se sua equipe preferir usar os termos atributos, estados e funções e tiver boas definições de trabalho, isso ajudará a melhorar a comunicação interna, mas você precisará ser flexível ao se comunicar fora desse grupo.

Os conceitos "famintos" e "sedentos" podem ser derivados de atributos básicos (por exemplo, glicose no sangue, nível de hidratação), então poderíamos pensar em estado como meta-atributo que é derivado de atributos base que podemos citar como True ou Falso com base no estado dos atributos base relevantes. Para o exemplo da luz, poderíamos pensar na luz como tendo os atributos applied_voltage e resistance e as funções voltage_switch() e shine() . O voltage_swich() é então uma função de alguma entrada (por exemplo, interruptor manual, luz, temporizador, etc.) e shine() é uma função de applied_voltage e resistance . Poderíamos declarar um meta-atributo chamado light_state que é verdadeiro 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.

    
por 04.05.2017 / 22:17
fonte
-2

O estado de um objeto é codificado em seus atributos, direta ou indiretamente. Por exemplo, se você quer que seu cachorro tenha sede, você pode deixar que ele tenha um

private boolean thirsty;

Alternativamente, você pode deixar algo como

private Date lastDrinkAt;

e conclua se a sua situação de cão está com sede, comparando a hora atual com a hora em que ela bebeu alguma coisa.

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

Depois, há classes que não possuem atributos, principalmente classes de utilitário. Mas normalmente você não quer criar uma instância deles neste caso.

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

    
por 05.01.2012 / 17:44
fonte
-3

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

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

    
por 05.01.2012 / 19:00
fonte