IV.3.3. Le Méthodes de programmations
utilisées
Etant donné que nous avons utilisé UML afin de
modéliser notre nouveau système, il faut savoir que choisir UML
pour la modélisation, est un fait implique certaines contraintes et
logique à appliquer au niveau de d'implémentation des classes
issues du diagramme de classe présenté plus haut, et ces
contraintes et logique sont essentiellement liés à la
méthode de programmation orientée objet, POO en sigle.
1. La Méthode objet
Cette méthode qui consiste à créer une
représentation informatique des éléments du monde
réel du monde auxquels on s'intéresse, sans forcément se
préoccuper de l'implémentation, ce qui signifie
indépendamment d'un langage de programmation.
Il s'agit donc d'identifier les objets présents dans le
système et d'isoler les données et les fonctions qu'ils
utilisent. En bref, c'est la description de ce qui est représenté
dans un diagramme de classe.
? Avantages de la POO
Choisir la méthode objet comme sa méthode de
programmation, présente un bon nombre d'avantage dont :
? La POO permet l'encapsulation : Le code constituant l'objet
est caché de l'utilisateur (l'utilisateur dont il est question ici c'est
celui qui se servira de vos objets afin d'animer le site ou l'application, et
non le visiteur qui demande la page depuis son navigateur, ou simplement
l'utilisateur de l'application).
43
44
Cela diminue le risque d'erreurs puisque l'utilisateur ne
pourra pas modifier le coeur même de votre code et évitera ainsi
beaucoup d'erreurs.
( Maintenance et évolutivité :
C'est-à-dire que la POO permet de concevoir une application dont les
différents constituants sont indépendants les uns des autres. De
ce fait, modifier un de ces constituants n'affectera pas les autres et
n'entraînera donc pas d'erreurs ou autres comportements erratiques, du
fait de la clarté du code vous retrouverez facilement les
éléments que vous souhaitez modifier.
( Possibilité de réutilisation :
L'indépendance de vos modules vous permet de les réutiliser dans
d'autres applications: module de news, galerie photo: ces
éléments sont présents sur une grande majorité de
sites, il est donc très intéressant de pouvoir les
réutiliser à chaque fois que ce sera nécessaire, sans
avoir à les réinventer!
·
· Inconvénients de
la POO
( La performance souffre parfois en utilisation
intensive du polymorphisme en temps d'exécution, patrons de conception
imbriqués et autres artifices POO.
( La redondance de code parfois imposée par
certaines contraintes et recommandations de l'OOP. Taille de la base de code
conséquente, résultat de l'accumulation des niveaux
d'abstraction.
( La sur-ingénierie ou Overengineering est un
piège qui guette les concepteurs (parfois expérimentés) et
qui peut causer des dégâts allant du retard jusqu'à
l'échec du projet.
( Exigence en savoir-faire en génie logiciel
pour les projets importants (architectes, ingénieurs, et
développeurs qualifiés en POO).
( Pas très pratique pour des petits projets ou
test de fonctionnalités non PPO. En somme, La réutilisation,
l'encapsulation, l'extensibilité et la maintenabilité ont parfois
des prix à payer : le temps et l'espace entre autre.
Il est important de notifier, qui l'existe des
méthodologies pouvant être combinées à la POO afin
d'accroître ces avantages en proposant une structuration bien
particulière et un niveau d'abstraction et d'organisation bien plus
élevé. Ces méthodologies sont connues sous le nom de
« designs patterns ».
2. Les Design patterns
Les designs patterns (en français patrons de
conception, Modèle de conception ou encore Motifs de conception)
représentent chacun un ensemble de bonnes pratiques de conception pour
un certain nombre de problème récurrents en programmation
orienté objet.
Ce concept de Designs patterns est issu des travaux de 4
chercheurs (Erich Gamma, Richard Helm, Ralph Johnson, et John Vlissides, groupe
de quatre chercheur connu sous le nom de « Gang of four » ou «
La bande des quatre »)
dans leur ouvrages intitulé « Design patterns :
Elements of Reusable Object-Oriented Software » édité en
1995 et proposant 23 motif de conception.
Il existe plusieurs types de patterns, mais dans le cadre de
notre implémentation, nous n'en avons utilisés que deux, à
savoir : le pattern singleton et le pattern DAO.
? Le Pattern Singleton
Le « singleton » [Gamma 95] est l'une des techniques
les plus utilisées en conception orientée objet. Il permet de
référencer l'instance d'une classe devant être unique par
construction. Certains objets techniques prennent en effet une
responsabilité particulière dans la gestion logique d'une
application.
C'est par exemple le cas d'objets comme le «
contrôleur des objets chargés en mémoire » ou le
« superviseur des vues », qui sont les seuls et uniques
représentants de leur classe. Ces objets sont le plus souvent
publiquement accessibles.
De tels cas de figure sont extrêmement fréquents
en conception objet, et le singleton est requis pour les concevoir.
Le singleton repose sur l'utilisation d'une opération
de classe, getInstance() :
Instance, chargée de rapporter à
l'appelant la référence de l'objet unique. De plus, le singleton
se charge automatiquement de construire l'objet lors du premier appel.
? Le Pattern DAO
Un objet d'accès aux données (en anglais Data
Access Object) est un patron de conception (en la langue de voltaire, un
modèle pour concevoir une solution) utilisé dans les
architectures logicielles objet. Ce modèle permet d'encapsuler la
façon dont un programme récupère les données d'un
système de stockage (fichier, BDD...).
Il fait donc abstraction de la façon dont les
données sont stockées au niveau des objets métier, Ainsi,
le changement du mode de stockage ne remet pas en cause le reste de
l'application. En effet, seules ces classes dites "techniques" seront à
modifier (et donc à ré-tester). Cette souplesse implique
cependant un coût additionnel, dû à une plus grande
complexité de mise en oeuvre.
| 
