J'ai lu The Early History of Smalltalk et il y a quelques mentions de "mission" qui me font douter de ma compréhension de sa signification:
Bien que la POO vienne de nombreuses motivations, deux étaient centrales. La solution à grande échelle consistait à trouver un meilleur schéma de module pour les systèmes complexes impliquant la dissimulation de détails, tandis que la solution à petite échelle consistait à trouver une version plus flexible de la tâche, puis à tenter de l'éliminer complètement.
(de 1960 à 1966 - Début de la programmation orientée objet et autres idées formatrices des années soixante , section I)
Ce que j'ai compris de Simula, c'est que vous pouvez désormais remplacer les liaisons et les tâches par des objectifs . La dernière chose que vous souhaitiez que tout programmeur fasse est de manipuler l'état interne, même s'il est présenté de manière figurative. Au lieu de cela, les objets doivent être présentés comme le site de comportements de niveau supérieur plus appropriés pour une utilisation en tant que composants dynamiques . (...) Il est regrettable qu’une grande partie de ce qu’on appelle la "programmation orientée objet" soit aujourd’hui simplement une programmation à l’ancienne avec des constructions plus sophistiquées. De nombreux programmes sont chargés d'opérations de type "affectation", effectuées maintenant par des procédures attachées plus coûteuses.
(de style "orienté objet" , Section IV)
Ai-je raison d'interpréter l'intention comme étant que les objets sont censés être des façades et que toute méthode (ou "message") ayant pour but de définir une variable d'instance sur un objet (c'est-à-dire une "affectation") est contraire à l'objectif? Cette interprétation semble être étayée par deux affirmations ultérieures de la section IV:
Quatre techniques utilisées ensemble - l’état persistant, le polymorphisme, l’instanciation et les méthodes comme objectifs de l’objet - représentent une grande partie de la puissance. Aucun de ceux-ci ne nécessite l'emploi d'un "langage orienté objet" - ALGOL 68 peut presque être transformé en ce style - et OOPL se concentre simplement sur l'esprit du concepteur dans une direction fructueuse particulière. Cependant, bien encapsuler est un engagement non seulement d'abstraction d'état, mais également d'éliminer les métaphores orientées État de la programmation.
...et:
Les déclarations de mission, même abstraites, expriment des objectifs de bas niveau et il en faudra plus pour que tout soit accompli. En général, nous ne voulons pas que le programmeur se moque de l'état, qu'il soit simulé ou non.
Serait-il juste de dire que des cas opaques et immuables sont encouragés ici? Ou est-ce simplement des changements d'état directs découragés? Par exemple, si j'ai une BankAccount
classe, il est OK d'avoir GetBalance
, Deposit
et les Withdraw
méthodes d'instance / messages; assurez-vous simplement qu'il n'y a pas de SetBalance
méthode d'instance / de message?