Les interfaces jouent un rôle important dans l'orientation des objets. Cependant, même si on ne vous enseigne que l'implémentation de "l'interface n'a pas d'implémentation, seulement la définition de la méthode!", Vous ne pouvez pas réaliser son importance si vous ne comprenez pas sa signification. Par conséquent, cette fois, je voudrais résumer la signification de l'interface en utilisant la collection Java comme exemple concret.
En conclusion, une interface signifie «rôle». En d'autres termes, il représente le comportement de l'interface.
Jetons un coup d'œil à l'interface Collection.
Collection L'interface racine de la hiérarchie des collections. Une collection représente un groupe d'objets qui sont ses éléments. Certaines collections autorisent la duplication d'éléments, mais d'autres non. De plus, certaines collections sont commandées et d'autres non.
En d'autres termes, une collection est une interface qui a un "rôle" d'un groupe d'objets spécifiques. Et la Collection elle-même ne précise pas si elle peut être dupliquée ou commandée.
Regardons maintenant Set et List, qui sont des interfaces qui héritent de Collection. Je pense qu'il y a beaucoup de gens qui connaissent mieux cela que la Collection.
Set Une collection sans éléments en double. Autrement dit, l'ensemble n'a pas de paire d'éléments e1 et e2 qui est e1.equals (e2) et n'a qu'un seul élément nul au plus. Comme son nom l'indique, cette interface modélise l'abstraction des ensembles en mathématiques.
List Une collection ordonnée. Aussi appelé une séquence. Les utilisateurs de cette interface ont un contrôle précis sur l'endroit où dans la liste chaque élément est inséré. Les utilisateurs peuvent accéder aux éléments par index de valeurs entières (position dans la liste) et rechercher des éléments dans la liste. Contrairement aux ensembles, les listes autorisent généralement les éléments dupliqués.
Pour les résumer dans un tableau,
rôle | Dupliquer | commande | |
---|---|---|---|
Collection | Groupe d'éléments | ? | ? |
Set | Ensemble d'éléments | × | ? |
List | Un groupe d'éléments ordonnés | ○ | ○ |
Puisque Set et List héritent de la classe Collection, vous pouvez voir qu'il s'agit d'interfaces avec des rôles plus spécifiques.
Regardons maintenant les méthodes de chaque interface (voir le JavaDoc listé ci-dessus pour les définitions, etc.). Collection spécifie les opérations pour les groupes telles que la taille (nombre d'éléments) et la suppression (suppression d'éléments). Set définit également fondamentalement des méthodes comme celles de Collection, mais List définit des méthodes liées aux index tels que indexOf (recherche de l'index de l'élément spécifié). Puisque Set n'a pas le concept d'index en premier lieu (il ne commande pas), le traitement d'index est un traitement qui appartient au rôle de List. En outre, en se concentrant sur la méthode appelée add, la méthode définie dans Collection est remplacée par Set et List, et l'explication de la méthode est différente pour chacun.
interface | Description de l'ajout |
---|---|
Collection | Garantit que l'élément spécifié est stocké dans cette collection. |
Set | Si l'élément spécifié ne fait pas partie de l'ensemble, il sera ajouté à l'ensemble. |
List | Ajoute l'élément spécifié à la fin de cette liste. |
Dans Collection, ajouter est une garantie de stockage, pas de traitement supplémentaire. C'est parce qu'il y a un rôle qui n'est pas ajouté si l'élément à ajouter existe déjà comme Set, donc à partir du rôle de Collection, le processus d'ajout est "parfois des éléments sont ajoutés et parfois ils ne sont pas ajoutés Parfois, mais au moins après avoir exécuté add, je vous garantis que l'élément que j'essaie d'ajouter est dans le groupe. " Chacun des ajouts d'ensemble et de liste a un contenu plus spécifique. Cela signifie que chacun a un "rôle d'interface" plus spécifique par héritage, ce qui rend le "rôle de méthode" plus spécifique. Remplacer une méthode d'une interface n'a pas beaucoup de sens en termes d'implémentation, mais on peut dire qu'il la remplace pour exprimer explicitement l'intention de «à quelle interface appartient la méthode».
J'espère que vous comprenez que chaque interface et sa méthode représentent une sorte de "rôle". Cependant, la question devient: "Pourquoi est-il important d'exprimer le rôle?" Avant d'expliquer cela, jetons un coup d'œil aux deux codes.
ArrayList<String> list = new ArrayList<String>();
list.add("abc");
List<String> list = new ArrayList<String>();
list.add("abc");
Je suis sûr que beaucoup de gens ont vu du code comme celui-ci. Normalement, le style d'écriture suivant est recommandé. La raison en est que le code ci-dessous est "un traitement dépendant du concept plus abstrait".
La raison pour laquelle écrire du code s'appuie sur des éléments abstraits est de séparer le traitement de la classe d'implémentation d'interface et de la classe qui l'utilise. Par exemple, supposons que vous souhaitiez changer le processus qui a utilisé ArrayList en LinkedList par la suite. Dans ce cas, les deux premiers codes ressembleraient à ceci:
LinkedList<String> list = new LinkedList<String>();
list.add("abc");
List<String> list = new LinkedList<String>();
list.add("abc");
À première vue, ces deux codes semblent avoir changé la première ligne. Cependant, en considérant la deuxième ligne du point de vue de l'intention du code, le code ci-dessous a toujours l'intention «d'ajouter à la liste», tandis que le code ci-dessus passe de «l'ajout à ArrayList» à «LinkedList». Il a changé pour l'intention de "ajouter". Par conséquent, il est nécessaire de confirmer que l'intention du code n'a pas changé en raison du changement de la classe d'implémentation.
Si vous écrivez votre propre classe d'implémentation, cela apportera une utilité encore plus grande. Tant qu'elle correspond au rôle de l'interface List, toute implémentation interne fera l'affaire. Du point de vue de l'utilisateur, il est possible d'écrire le processus sous la garantie que "la classe d'implémentation de l'interface List implémente pour satisfaire ce rôle". L'essentiel est que si l'utilisateur ne dépend que de l'interface, il ou elle peut écrire le processus sans la classe d'implémentation. C'est exactement "la séparation du côté utilisateur et de la classe d'implémentation".
Je pense avoir vu diverses choses et saisi la signification de l'interface. Cependant, ces idées reposent sur l'hypothèse que la classe d'implémentation est implémentée en fonction du rôle de l'interface, et que ce rôle est utilisé pour décrire le traitement de l'utilisateur. Par conséquent, il est important d'être conscient du rôle de chaque interface lors de sa mise en œuvre, et vous pouvez maximiser les avantages en créant votre propre interface avec le rôle à l'esprit.
Recommended Posts