Peut-on dire que les objets ont des attributs, des états et des comportements?

Je lisais l'introduction d'Oracle aux concepts de POO et je suis tombé sur cette description:

Les objets du monde réel partagent deux caractéristiques: ils ont tous un état et un comportement. Les chiens ont un état (nom, couleur, race, faim) et un comportement (aboyer, aller chercher, remuer la queue). Les objets logiciels sont conceptuellement similaires aux objets du monde réel: ils se composent également de l'état et du comportement associé.

Mon problème avec ce passage est que lors de la description de l' état, ses attributs de mixage s'y trouvent également. Par exemple, le nom et la couleur d'un chien sont ses attributs, tandis qu'il est affamé ou thursty sont ses états.

Donc, à mon avis, il est plus précis de diviser les caractéristiques des objets en trois parties: les attributs, les états et les comportements .

Bien sûr, en traduisant cela dans un langage de programmation, je peux voir que la partition triple devient double, car les attributs et les états seront stockés dans des champs / variables, tandis que les comportements seront stockés dans des méthodes / fonctions.

Mais conceptuellement parlant, il est plus logique de séparer les 3 choses.

Voici un autre exemple: considérons une lampe. Dire que la taille de la lampe et le fait qu'elle soit allumée ou non sont des états à mon avis. La taille de la lampe est un attribut, pas un état, tandis qu'elle est allumée ou éteinte est un état.

Ou ai-je raté quelque chose?

Vous avez raison en ce que les objets sont constitués d'attributs, d'états et de comportement, si vous définissez des attributs pour signifier des caractéristiques non changeantes d'une instance. En fait, il est important de faire cette distinction, car il existe des objets qui ne contiennent que des attributs (dans votre sens) et aucun état; ils sont appelés immuables et ils sont très utiles en programmation.

Cette définition en trois parties est en effet représentée dans les langages de programmation, par exemple en utilisant le finalmot - clé en Java ou le readonlymot - clé en C # pour désigner des données d'instance qui peuvent ne pas changer pendant la durée de vie de l'instance.

Je dois cependant ajouter que les données d'instance inchangées ne sont généralement pas appelées attributs. Nous avons tendance à les qualifier de «données finales», «en lecture seule» ou «constantes», selon la langue que nous utilisons. Le terme approprié pour eux serait «invariants», mais alors ce mot n'est pas fréquemment utilisé dans ce sens; il est plus souvent utilisé pour d'autres choses.

Je pense qu'il est plus exact de dire que les objets n'ont que deux caractéristiques. Prenons l'exemple d'Oracle:

Les chiens ont un état (nom, couleur, race, faim) et un comportement (aboyer, aller chercher, remuer la queue). Les objets logiciels sont conceptuellement similaires aux objets du monde réel: ils se composent également de l'état et du comportement associé.

Le fait que les valeurs (état) pour le nom, la couleur, la race et la faim sont stockées dans l'objet dans des attributs est un détail d'implémentation. Vous n'avez pas vraiment besoin d'attributs.

Si vous souhaitez inclure des attributs en tant que troisième caractéristique, vous devez également inclure des méthodes en tant que quatrième, car les comportements (comme l'état) des objets peuvent également changer. L'état et le comportement sont deux caractéristiques abstraites des objets. Les attributs et les méthodes sont des implémentations concrètes de ces concepts.

L'état est un ensemble d'attributs et de valeurs correspondantes, donc de mon point de vue, vous n'avez pas raison (et vous créez une complexité supplémentaire inutile à une définition simple).

Nous pouvons classer les choses d'innombrables façons et chaque classification n'aurait pas de «bonne réponse». Il y a un avantage à classer les choses uniquement si la classification conduit à une compréhension plus approfondie ou à une meilleure communication. Si votre équipe préfère utiliser les termes attributs, états et fonctions et possède de bonnes définitions de travail pour ceux-ci, cela aidera à améliorer la communication interne, mais vous devez être flexible lorsque vous communiquez en dehors de ce groupe.

Les concepts «faim» et «soif» peuvent être dérivés d'attributs de base (par exemple, la glycémie, le niveau d'hydratation) afin que nous puissions considérer l'état comme un méta-attribut dérivé d'attributs de base que nous pouvons faire passer à Vrai ou Faux en fonction de l'état des attributs de base pertinents. Pour l'exemple de la lumière, nous pourrions penser que la lumière a les attributs applied_voltageet resistanceet les fonctions voltage_switch()et shine(). Le voltage_swich()est alors une fonction de certaines entrées (par exemple interrupteur manuel, lumière, minuterie, etc.) et shine()est une fonction de applied_voltageet resistance. Nous pourrions déclarer un méta-attribut appelé light_stateTrue ou False pour aider à construire mentalement l'objet, mais en fin de compte, ces idées ne sont que des constructions mentales que nous utilisons pour organiser notre travail.

L'état d'un objet est codé dans ses attributs, directement ou indirectement. Par exemple, si vous voulez que votre chien ait soif, vous pouvez lui laisser un

private boolean thirsty;

Alternativement, vous pouvez lui laisser quelque chose comme

private Date lastDrinkAt;

et concluez si votre instance de chien a soif en comparant l'heure actuelle avec la dernière fois qu'il a bu quelque chose.

Quoi qu'il en soit, l'état de vos objets se situe dans ses attributs.

Ensuite, il y a des classes qui n'ont pas d'attributs, principalement des classes utilitaires. Mais vous ne voulez généralement pas en créer une instance non plus dans ce cas.

Afin de pouvoir raisonner sur les déclarations, les scientifiques s'en tiennent généralement au principe de la minimalité. Je pense que c'est pourquoi Oracle n'a pas mentionné explicitement l'état. Il peut être dérivé de la valeur des attributs.

Les connexions avec le monde réel sont erronées. Voici comment je l'enseignerais (approche c ++):

1. Les ordinateurs prennent en charge deux formats de stockage différents: données et code
2. les données ressemblent à des bits 010101010101
3. le code ressemble à des instructions asm
4. les bits de données ont deux valeurs différentes, c'est 0 ou 1
5. les données sont abstraites en types de données: int i = 1; est juste une notation courte à quelques bits 0000001
6. le code ressemblera à une fonction: int f (int a) {return a + a + a; } est une notation courte pour certaines instructions asm
7. lorsque vous avez plusieurs variables, vous les combinez en une structure: int a; flotteur b; peut être placé dans une structure AB {int a; flotteur b; };
8. lorsque vous y combinez quelques morceaux de code, vous obtenez une classe: class ABf {int a; flotteur b; float sum (float c) const {return a + b + c; }};
9. Ensuite, pour les données, nous avons des noms de variables qui peuvent être utilisés pour trouver la valeur: a + b + c pour accéder aux données.
10. Et puis nous avons des appels de fonction normaux: int k = f (10); pour accéder aux instructions asm "stockées" dans la fonction f.
11. Il y a ensuite les instances d'objets: ABf var;
12. Et la fonction membre appelle: int k2 = var.sum (10.0);
13. les fonctions ont des types int f (int);
14. les fonctions membres ont des types int ABf :: sum (float);
15. Il y a ce pointeur de type ABf *
16. des variables comme a et b et c dépendent du contexte, si elles sont à l'intérieur d'une fonction membre, elles peuvent signifier ceci -> b, ou simplement b.
17. Fonctions membres int ABf :: sum (float c) est juste une notation courte pour int sum (ABf * this, float c);
18. le mot "état" signifie simplement la même chose que les données
19. le mot "comportement" signifie simplement la même chose que le code
20. le mot "attribut" signifie simplement la même chose que les données.

Il n'y a donc pas vraiment de différence entre l'état et l'attribut. C'est juste une collection aléatoire de bits. C'est juste une distinction arbitraire pour les séparer. Juste besoin de savoir à quoi il sert d'alias.