====== 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?// {{ :java:dp:adapter-illustration.png?300 |}} 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'[[https://docs.oracle.com/javase/8/docs/api/java/lang/String.html|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? Voici la classe String de java (uniquement ce qui est public): {{ :java:dp:uml-string.png?400 |Modèle UML de la classe String}} Avez-vous vraiment envie de redéfinir toutes ces méthodes? ==== Deuxième approche: la composition ==== Admettons que les fonctionnalités utiles de String pour notre problème sont les suivantes: {{ :java:dp:uml-stringutile.png?300 |Fonctionnalités utiles de String: length, contains, equals, compareTo}}