Ce chapitre distingue l'approche dite procédurale, axée sur les grandes activités de l'application, de l'approche objet, axée sur les acteurs de la simulation et la manière dont ils interagissent. Nous illustrons cette distinction à l'aide de la simulation d'un petit écosystème.
L'addition des méthodes dans la classe, dès que celles-ci portent sur un des attributs de la classe, transforme ces dernières de simples récipients d'informations en véritables acteurs ; l'objet fait plus qu'il n'est. Il ne se borne pas simplement à stocker son état ; il est surtout le premier responsable des modifications que celui-ci subit. Il sait et il fait, tout à la fois. Q'un second objet, quelconque, désire se renseigner sur l’état du premier ou d'entreprendre de modifier cet état, il devra passer par les méthodes de ce premier objet qui, seules, ont la permission de lire ou transformer cet état. L'objet devra toujours être accompagné de son mode d'emploi, défini dans une structure de donnée à part : son interface.
Transition vers l'objet il est indéniable qu'il existe aujourd'hui deux manière de penser les développements logiciels : la manière dite « procédurale » (C, Pascal, Fortran...) et la manière dite « orienté objet » (Java, C#, C++),aujourd'hui, l'orienté objet prend le pas sur le procédurale. De manière à différencier ces deux approches, nous allons simuler un écosystème dans lequel, comme indiqué dans la figure ci-dessous, évoluent un prédateur (le lion), une proie (l'oiseau) et des ressources, eau et plante, nécessaire à la survie des deux animaux.
Simulation de l'écosystème mise en pratique : Voici les scénarios, la proie se déplace vers l'eau, vers la plante, ou afin de fuir le prédateur; elle agit en fonction du premier de ces objets qu'elle repère. La vision, tant de la proie que du prédateur, est indiquée par une ligne, qui part d'un des coins de l'animal et balaie l'écran. Quand la ligne de vision traverse un objet, quel qu'il soit, l'objet est considéré comme repéré, la vision ne quitte plus l'objet, et l'animal se dirige vers la cible ou la fuit. Le prédateur se déplace vers l'eau ou poursuit la proie, la aussi en fonction de premier des deux objets perçus. L'énergie selon laquelle les deux animaux se déplacent décroit au fur et à mesure des déplacements, et conditionne leur vitesse de déplacement.
Dès que le prédateur rencontre la proie, il la mange. Dès que le prédateur ou la proie rencontre l'eau, ils se ressourcent (leur énergie augmente) et l'eau diminue de quantité (visuellement la taille de la zone d'eau diminue). Dès que la proie rencontre la plante, elle se ressource (son énergie augmente également) et la plante diminue de quantité (sa taille diminue). Enfin, la plante pousse lentement avec le temps, alors que la zone d'eau, au contraire, s'évapore.
Analyse :
Fonction Principale : Quelles sont les fonctions que tous les objets doivent accomplir ici ?
- Tout d'abord, la proie et le prédateur doivent se déplacer. On commencera donc à penser et coder les déplacements des animaux, ensemble. Le fait de les traiter ensemble, même s'il s'agit de deux entités différentes, est très important. Il faudra préalablement que chacun des animaux repère une cible. La fonctionnalité « déplacement » devra faire appel à une nouvelle fonctionnalité, de « repérage », qui elle également, concerne les deux objets. En effet, les deux objets doivent se repérer entre eux : le prédateur cherche la proie, la proie cherche la plante et à éviter le prédateur, et tous deux cherchent l'eau. Le repérage se fait à l'aide de la vision, un bloc procédural constitué de deux fonctionnalités semblables que l'on associe à chaque animal et qui n'agira que pendant le repérage.
- Une deuxième grande fonctionnalité est le ressourcement de la proie et du prédateur. Ce ressourcement concerne à nouveau tous les deux objets animaux, pour la proie comme pour le prédateur, il fonctionnera différemment selon la ressource rencontrée. Par exemple, lorsque la proie rencontre la plante, elle la mange et la plante s'en trouve diminuée. Lorsque le prédateur rencontre la proie, il la mange, et la proie, morte, disparaît de l'écran .
- La troisième fonctionnalité est l'évolution dans le temps des ressources, la plante poussant et l'eau s'évaporant.
Le programme principal se trouvera finalement constitué de tous les objets du problème, et ensuite de trois grandes procédures : « déplacement », « ressourcement », « évolutions des ressources ». La première d'entre elle fait appel à une nouvelle procédure de repérage entre les objets. Cette décomposition fonctionnelle est représentée ci-dessous.
Conception objet, la pratique orientée objet cherche d'abord à identifier les acteurs du problème et à les transformer en classe, regroupant leurs caractéristiques structurelles et comportementales. Les acteurs ne se limitent pas à exister structurellement, ils se démarquent surtout par le comportement adopté, par ce qu'ils font, pour eux et pour les autres. Ce ne sont plus les grandes fonctions comme en orientée procédurale qui guident la construction modulaire du logiciel, mais bien les classes/acteurs eux-mêmes. Les acteurs ici sont la proie, le prédateur, l'eau, la plante. Une fois que l'on a établit les attributs de chacun la suite consiste à réaliser une nouvelle analyse fonctionnelle, mais particularisée à chaque acteurs.
Que font, pris individuellement, ces acteurs ? A partant du plus simple d'entre eux :
- La plante pousse et peut diminuer sa quantité.
- L'eau s'évapore et peut également diminuer sa quantité.
- La proie peut se déplacer, et doit pour cela repérer les autres objets. A cette fin, elle utilisera, comme le prédateur, une nouvelle classe vision,constituée d'une longueur, et à même de repérer quelque chose dans son champs. Mais la proie devra d'interagir avec les autres classes. La proie peut boire l'eau et manger la plante. L'interaction avec les autres classes se produit.
- Le prédateur, à son tour, se déplacer en fonction des cibles, et peut boire l'eau et manger la proie.
Les liens entre objets sont maintenant représentés comme dans figure ci-dessous.
Dépendance fonctionnelle versus indépendance logicielle, alors que l'exécution d'un programme OO repose sur l'essentiel sur un jeu d'interaction entre classes dépendantes, tout est syntaxiquement mis en oeuvre lors du développement logiciel pour maintenir une grande indépendance entre les classes. Cette indépendance au cours du développement favorise tant la répartition des tâches entre les programmeurs que la stabilité des codes durant leur maintenance, leur réexploitation dans des contextes différents et leur évolution.
En substance, les dépendances entre classes se pensent au coup et deux à deux, et ne sont pas noyées dans la mise en commun de toutes les classes dans les modules d'activité logicielle. Cela conduit à une conception de la programmation sous forme d'un ensemble de couples client-fournisseur (ou serveur) dans laquelle toute classe sera tour à tour client et fournisseur d'une ou de plusieurs autres. Une conception où les classes se rendent mutuellement des services, ou se délèguent mutuellement des resposanbilités, pointe à l'horizon.Une conception bien plus modulaire que la précédente, car le monde contient plus d'acteurs que de fonctions possibles. Les grandes fonctions génériques sont redéfinies pour chaque acteur.
Il est parfaitement incorrect de clamer haut et fort que les performances en consommation des ressources informatiques (temps calcul et mémoire) des programmes OO sont supérieures en général à celles des programmes procéduraux remplissant les mêmes taches. Tout concourt à faire des programmes OO de grands consommateurs de mémoire et de temps de calcul. Les seuls temps et ressource réellement épargnés sont ceux des programmeurs, tant lors du développement que lors de la maintenance et de l'évolution de leur code. L'OO considère simplement, à juste titre que le temps programmeur est plus précieux et plus onéreux que le temps machine.
Aucun commentaire:
Enregistrer un commentaire