Matthieu PARIS
Pour lancer le projet : php index.php connect4
Mécanisme d'inversion de dépendance :
- Dans le fichier Application.php à la ligne 57.
Diagramme de classe :
Lien : https://drive.google.com/file/d/1foZFUeQLV-mzl4SgYLYQaFLwhbWJ8aHi/view?usp=sharing
Héritage et Composition :
L'héritage
est un des grands principes de la programmation orientée objet (POO). Elle permet d'étendre une classe à une autre classe dite "fille" qui hérite de toutes les méthodes publiques et protégées de la classe parente. Tant qu'une classe n'écrase pas ces méthodes, elles conservent leur fonctionnalité d'origine.
L'héritage est très utile pour définir et abstraire certaines fonctionnalités communes à plusieurs classes, tout en permettant la mise en place de fonctionnalités supplémentaires dans les classes enfants, sans avoir à réimplémenter en leur sein toutes les fonctionnalités communes.
Cependant, il existe des inconvénients tels que la classe dérivée a accès aux propriétés non privées de la classe mère, et peut par ce biais affecter son invariant, provoquant ainsi des bugs et autres comportements non souhaités. C’est une des raisons qui font que l’utilisation du mot-clefs protected est aussi dangereuse, puisqu’il revient à partager des informations sensibles avec ses classes filles.
Une composition
symbolise l'existence d'une agrégation particulière, dite 'forte', entre deux entités (classes).
- Le premier point est une directe opposition à l'héritage puisque la composition implique une réutilisation en mode "boite noire" où seules les informations publiques de la classe réutilisées sont connues et manipulables. L’invariant de celle-ci est donc protégé.
- Le second point à trait à la relation qu’on crée entre la classe contenue et la classe contenante : au lieu d’implémenter une relation du type "is-a", c’est une relation du type "has-a" qui est créée.
On remarque à ce propos que si la notion de sous-type n’est pas respectée, forcer l’héritage est une erreur, au regard des risques de non-respect des principes de POO déjà énoncés.Il devient alors clair que la composition, outre le fait qu’elle sera un choix souvent judicieux, forme aussi un rempart à considérer contre des erreurs d’architecture qui pourrait déboucher sur des problèmes plus vastes.
La composition permet la réutilisation du code sans hériter la classe mère, mais pour l’héritage on doit hériter la classe mère pour toute réutilisation de code ou de fonctionnalité. Une autre différence qui découle de ce fait est que, en utilisant la composition, on peut réutiliser du code pour une classe finale, ce qui n’est pas extensible, mais Héritage ne peut pas réutiliser le code dans de tels cas. Également en utilisant Composition, on peut aussi réutiliser le code de nombreuses classes car elles sont déclarées comme une simple variable membre, mais avec Héritage, on ne peut réutiliser le code d’une seule classe car on ne peut hériter qu’une seule classe.
Dans la plupart des cas, il est préférable de choisir la composition. L’héritage doit être réservé aux cas qui non seulement lui sont à priori acquis (c’est à dire les cas où transparaît une relation du type "is-a") mais qui en plus respecte la définition d’un sous-type. En outre, la composition permet souvent de simplifier les relations entre les objets, rendant le code moins interdépendant et donc plus versatile : en deux mots, plus réutilisable.
510 mots.