¿Podemos decir que los objetos tienen atributos, estados y comportamientos?

Estaba leyendo la introducción de Oracle a los conceptos de OOP y me encontré con esta descripción:

Los objetos del mundo real comparten dos características: todos tienen estado y comportamiento. Los perros tienen estado (nombre, color, raza, hambre) y comportamiento (ladrar, buscar, mover la cola). Los objetos de software son conceptualmente similares a los objetos del mundo real: también consisten en estado y comportamiento relacionado.

Mi problema con ese pasaje es que al describir el estado también mezcla sus atributos . Por ejemplo, el nombre y el color de un perro son sus atributos, mientras que tener hambre o sed son sus estados.

Entonces, en mi opinión, es más preciso dividir las características de los objetos en tres partes: atributos, estados y comportamientos .

Claro, cuando traduzco esto a un lenguaje de programación, puedo ver que la partición triple se convierte en una doble, porque tanto los atributos como los estados se almacenarán en campos / variables, mientras que los comportamientos se almacenarán en métodos / funciones.

Pero conceptualmente hablando tiene más sentido tener las 3 cosas separadas.

Aquí hay otro ejemplo: considere una lámpara. En mi opinión, decir que tanto el tamaño de la lámpara como si está encendida o no son estados es una exageración. El tamaño de la lámpara es un atributo, no un estado, mientras que se enciende o apaga es un estado.

¿O me perdí algo?

Tiene razón en que los objetos consisten en atributos, estados y comportamiento, si define atributos para que signifiquen características que no cambian de una instancia. De hecho, es importante hacer esta distinción, porque existen objetos que contienen solo atributos (en su sentido) y ningún estado; se llaman inmutables y son muy útiles en la programación.

Esta definición de tres partes está representada en los lenguajes de programación, por ejemplo, usando la finalpalabra clave en Java o la readonlypalabra clave en C # para denotar datos de instancia que pueden no cambiar durante la vida útil de la instancia.

Sin embargo, debo agregar que los datos de instancia que no cambian generalmente no se llaman atributos. Tendemos a hablar de ellos como 'final' o 'solo lectura' o 'datos constantes' dependiendo del idioma que estemos usando. El término apropiado para ellos sería 'invariantes', pero entonces esta palabra no se usa con frecuencia en este sentido; se usa más a menudo para otras cosas.

Creo que es más preciso decir que los objetos tienen solo dos características. Tomando el ejemplo de Oracle:

Los perros tienen estado (nombre, color, raza, hambre) y comportamiento (ladrar, buscar, mover la cola). Los objetos de software son conceptualmente similares a los objetos del mundo real: también consisten en estado y comportamiento relacionado.

El hecho de que los valores (estado) para nombre, color, raza y hambre se almacenen en el objeto en atributos es un detalle de implementación. Realmente no necesitas atributos en absoluto.

Si vas a incluir atributos como una tercera característica, entonces también deberías incluir métodos como cuarta, ya que los comportamientos (como el estado) de los objetos también pueden cambiar. Estado y comportamiento son dos características abstractas de los objetos. Los atributos y los métodos son implementaciones concretas de esos conceptos.

El estado es un conjunto de atributos y valores correspondientes, por lo que desde mi punto de vista, no tiene razón (y está creando una complejidad adicional innecesaria para la definición simple).

Podemos clasificar las cosas de innumerables maneras y cada clasificación no tendría "respuesta correcta". Hay un beneficio en clasificar las cosas solo si la clasificación conduce a una comprensión más profunda o para mejorar la comunicación. Si su equipo prefiere usar los términos atributos, estados y funciones y tiene buenas definiciones de trabajo para esto, esto ayudará a mejorar la comunicación interna, pero debe ser flexible al comunicarse fuera de este grupo.

Los conceptos "hambriento" y "sediento" pueden derivarse de atributos básicos (p. Ej., Glucosa en sangre, nivel de hidratación), por lo que podríamos pensar en el estado como un metaatributo que se deriva de los atributos básicos que podemos cambiar a Verdadero o Falso según El estado de los atributos base relevantes. Para el ejemplo de la luz, podríamos pensar en la luz que tienen los atributos applied_voltagey los resistancey las funciones voltage_switch()y shine(). El voltage_swich()es entonces una función de alguna entrada (por ejemplo, interruptor manual, luz, temporizador, etc.) y shine()es una función de applied_voltagey resistance. Podríamos declarar un meta-atributo llamado light_stateque es Verdadero o Falso para ayudar a construir mentalmente el objeto, pero al final estas ideas son solo construcciones mentales que usamos para organizar nuestro trabajo.

El estado de un objeto está codificado en sus atributos, ya sea directa o indirectamente. Por ejemplo, si quieres que tu perro tenga sed, puedes dejar que tenga

private boolean thirsty;

Alternativamente, puedes dejar que tenga algo como

private Date lastDrinkAt;

y concluya si su instancia de perro tiene sed comparando la hora actual con la última vez que bebió algo.

De cualquier manera, el estado de sus objetos se encuentra dentro de sus atributos.

Luego hay clases que no tienen atributos, principalmente clases de utilidad. Pero, por lo general, tampoco desea crear una instancia de ellos en este caso.

En aras de poder razonar sobre las declaraciones, los científicos generalmente se adhieren al principio de minimidad. Creo que es por eso que Oracle no mencionó el estado explícitamente. Se puede derivar del valor de los atributos.

Las conexiones del mundo real están equivocadas. Así es como lo enseñaría (enfoque c ++):

1. Las computadoras admiten dos formatos de almacenamiento diferentes: datos y código
2. los datos parecen bits 010101010101
3. el código parece instrucciones asm
4. los bits de datos tienen dos valores diferentes, es 0 o 1
5. los datos se abstraen a los tipos de datos: int i = 1; es una notación corta a algunos bits 0000001
6. el código se verá como una función: int f (int a) {return a + a + a; } es una notación corta para algunas instrucciones asm
7. cuando tiene varias variables, las combina en una estructura: int a; flotador b; se puede colocar en una estructura AB {int a; flotador b; };
8. cuando combina algunas piezas de código, obtiene una clase: class ABf {int a; flotador b; suma flotante (flotante c) const {devuelve a + b + c; }};
9. Luego, para los datos tenemos nombres de variables que se pueden usar para encontrar el valor: a + b + c para acceder a los datos.
10. Y luego tenemos llamadas a funciones normales: int k = f (10); para acceder a las instrucciones asm "almacenadas" dentro de la función f.
11. Luego hay instancias de objeto: ABf var;
12. Y la función miembro llama: int k2 = var.sum (10.0);
13. las funciones tienen tipos int f (int);
14. las funciones miembro tienen tipos int ABf :: sum (float);
15. Hay este puntero con tipo ABf *
16. variables como a y b y c dependen del contexto, si están dentro de la función miembro, podrían significar esto-> b, o simplemente b.
17. Funciones miembro int ABf :: sum (float c) es una notación corta para int sum (ABf * this, float c);
18. la palabra "estado" solo significa lo mismo que datos
19. la palabra "comportamiento" solo significa lo mismo que el código
20. la palabra "atributo" solo significa lo mismo que datos.

Entonces, en realidad no hay nada diferente entre estado y atributo. Es solo una colección aleatoria de bits. Es solo una distinción arbitraria separarlos. Solo necesito saber para qué es el alias.