Table des matières
Le design pattern Adapter
Vous avez besoin de certaines fonctionnalités d'un objet qui répond en partie à vos besoins, mais cet objet propose également de nombreuses fonctionnalités que vous ne voulez pas exposer ou utiliser?
La pattern Adapter illustre toute la puissance et l'intérêt de la POO: vous allez pouvoir encapsuler les comportements intéressants et exposer uniquement ce qui vous intéresse!
Un premier exemple
Vous souhaitez disposer d'une classe qui représente un mot de passe.
Un mot de passe:
- doit contenir au moins une majuscule
- doit contenir au moins une minuscule
- doit au moins un chiffre
- doit faire au moins 8 caractères.
Un mot de passe est une chaîne de caractères. Vous pensez tout de suite à la classe String de java, mais en regardant l'API de String, vous vous rendez compte que de nombreuses méthodes ne vous sont pas utiles.
Pire même: elle peuvent se révéler dangereuses pour représenter un mot de passe (pas de contrôle de validité, possibilité de modifier sans contrôle le mot de passe, etc.).
Première approche naïve: héritage
La première solution semble être l'héritage: créer une classe MotDePasse dérivant de String et redéfinissant les méthodes qui ne conviennent pas.
Quel problème cela pose-t-il?
<spoiler|Un indice?> Voici la classe String de java (uniquement ce qui est public):
Avez-vous vraiment envie de redéfinir toutes ces méthodes? </spoiler>