C'est une question d' implémentation versus d' implication . Les propriétés étaient en POO avant que C ++ ou Java n'entrent en scène (elles étaient là, avec une certaine rugosité autour des bords, dans Simula, et elles sont fondamentales pour Smalltalk). Les entités avec des propriétés sont conceptuellement différentes des valeurs avec du code attaché. Les préfixes get & set dans certaines conventions linguistiques ne servent qu'à brouiller les eaux; ils vous font prendre conscience de la différence entre les champs et les propriétés, en supposant que les champs peuvent être accédés directement sans get / set d'une manière idiomatique à la langue, et c'est une fuite.
Le but de la POO est de traiter les choses comme si elles étaient des entités dans le monde "réel", pas seulement comme des structures avec du code mélangé. Un autre programmeur devrait avoir besoin de savoir très, très peu de choses sur la façon dont j'ai implémenté les choses, et ne devrait pas du tout se préoccuper de laquelle des différentes valeurs qu’elles sont autorisées à obtenir et / ou définir sont réelles et lesquelles sont virtuelles. Si vous rencontrez un de mes vecteurs, vous ne devriez pas avoir besoin de savoir si je stocke l'angle et la magnitude ou des composants réels et imaginaires internes à l'objet vectoriel. Si je change la représentation dans la version 2.0 de ma bibliothèque, cela ne devrait pas du tout affecter votre code (bien que vous souhaitiez peut-être profiter des nouvelles fonctionnalités intéressantes). De même, certaines entités peuvent avoir des propriétés qui dépendent de données externes à l'entité, mais qui sont sans aucun doute des propriétés d'un point de vue lexical. Vous demandez aux gens "quel âge avez-vous", pas "veuillez effectuer le calcul qui me révélera votre âge", même si vous savez que les données disponibles pour cet "objet" sont la date de naissance (un membre privé immuable) et celle d'aujourd'hui date (propriété environnementale publique à incrémentation automatique, dépendante du fuseau horaire, de l'heure d'été et de la ligne de date internationale). L'âge est une propriété, pas une méthode, même s'il faut un certain calcul pour y arriver et ne peut pas (sauf dans les représentations par ordinateur jouet d'objets avec des durées de vie artificiellement limitées) être stocké comme un champ. même si vous savez que les données disponibles pour cet "objet" sont la date de naissance (un membre privé immuable) et la date d'aujourd'hui (une propriété environnementale publique à incrémentation automatique, en fonction du fuseau horaire, de l'heure d'été et de la ligne de date internationale ). L'âge est une propriété, pas une méthode, même s'il faut un certain calcul pour y arriver et ne peut pas (sauf dans les représentations par ordinateur jouet d'objets avec des durées de vie artificiellement limitées) être stocké comme un champ. même si vous savez que les données disponibles pour cet "objet" sont la date de naissance (un membre privé immuable) et la date d'aujourd'hui (une propriété environnementale publique à incrémentation automatique, en fonction du fuseau horaire, de l'heure d'été et de la ligne de date internationale ). L'âge est une propriété, pas une méthode, même s'il faut un certain calcul pour y arriver et ne peut pas (sauf dans les représentations par ordinateur jouet d'objets avec des durées de vie artificiellement limitées) être stocké comme un champ.
Plutôt que de considérer les propriétés comme l'enfant bâtard des champs et des méthodes, c'est beaucoup plus satisfaisant que les méthodes comme une sorte de propriété spécialisée - des choses que vos entités peuvent faire plutôt que des choses qu'elles sont. Sinon, vous ne traitez pas conceptuellement avec des objets / entités, vous traitez avec des collections de données auxquelles du code est attaché. Les implémentations peuvent être identiques, mais les implications sont différentes.
Il va sans dire, cependant, que cette abstraction a un coût. Si un programmeur utilisant une classe ne peut pas dire s'il accède aux données telles qu'elles sont stockées ou obtient / définit des valeurs qui doivent être calculées, alors il y aura un niveau auquel le langage est également nécessairement incertain (et peut donc exiger que tout nécessite un code intermédiaire entre les accesseurs / sélecteurs et les valeurs). Il n'y a rien de mal conceptuellement avec les "structures avec du code" - elles peuvent certainement être beaucoup plus efficaces - mais elles fuient l'implémentation partout, et c'est l'une des choses que la POO est censée éliminer.