Cet article décrit l'utilisation des interfaces Java et des classes abstraites. Partagez-le pour votre référence, comme suit:
interface
1 Parce que Java ne prend pas en charge l'héritage multiple, avec des interfaces, une classe ne peut hériter que d'une classe parent, mais peut implémenter plusieurs interfaces, et l'interface elle-même peut également hériter de plusieurs interfaces.
2 Les variables membre de l'interface sont du type final statique publique par défaut. Initialisation qui doit être affichée.
3 Les méthodes de l'interface sont par défaut du public. Déclaration implicite.
4 L'interface n'a pas de constructeur et ne peut pas être instanciée.
5 Une interface ne peut pas implémenter une autre interface, mais peut hériter de plusieurs interfaces.
6 Si une classe implémente une interface, toutes les méthodes abstraites de l'interface doivent être implémentées, sinon la classe doit être définie comme une classe abstraite.
Classe abstraite
1 Si une classe est déclarée abstraite, cette classe ne peut pas générer d'objets et ne peut être utilisée qu'héritée.
2 Les méthodes abstraites doivent exister dans les classes abstraites.
3 Il peut y avoir des variables générales et des méthodes générales dans les classes abstraites.
4 Les sous-classes héritent d'une classe abstraite doit implémenter ses méthodes abstraites à moins que la sous-classe soit une classe abstraite.
private void print () {}; Cette déclaration représente l'implémentation vide de la méthode.
Abstract void print (); Cette déclaration représente l'abstraction de la méthode, sans implémentation.
La différence entre l'interface et la classe abstraite
1 L'interface ne peut contenir que des méthodes abstraites et les classes abstraites peuvent contenir des méthodes ordinaires.
2 L'interface ne peut définir que des propriétés constantes statiques. Les classes abstraites peuvent définir à la fois les propriétés ordinaires et les propriétés constantes statiques.
3 L'interface ne contient pas de méthodes de constructeur et les classes abstraites peuvent contenir des méthodes de constructeur.
La classe abstraite ne peut pas être instanciée, mais ne signifie pas qu'elle ne peut pas avoir de constructeur. La classe abstraite peut avoir un constructeur et est une classe de remplacement.
1 L'interface est le noyau, qui définit ce qu'il faut faire et contient de nombreuses méthodes, mais ne définit pas comment ces méthodes doivent être faites.
2 Si de nombreuses classes implémentent une interface, chacune d'elles doit implémenter ces méthodes dans le code.
3 Si les implémentations de certaines classes ont quelque chose en commun, une classe abstraite peut être abstraite pour permettre à la classe abstraite d'implémenter le code commun de l'interface, tandis que ces méthodes personnalisées sont implémentées par chaque sous-classe.
Par conséquent, les classes abstraites sont conçues pour simplifier la mise en œuvre des interfaces. Ils fournissent non seulement la mise en œuvre des méthodes publiques, vous permettant de vous développer rapidement, mais permettent également à vos classes de mettre en œuvre toutes les méthodes par elles-mêmes sans problèmes de couplage serrés.
L'application est très simple
1. Définissez d'abord les interfaces
2 S'il existe plusieurs implémentations d'interface qui ont des pièces communes, utilisez des classes abstraites et intégrez-les.
La différence entre l'interface et la classe-Résumé, je crois que vous ne serez pas confus après l'avoir lu
Je pense que pour les programmeurs qui utilisent des langages de programmation orientés objet, le terme "interface" doit être familier, mais je me demande si vous avez de tels doutes: quel est le but d'une interface? Quelle est la différence entre les classes abstraites et les classes abstraites? Les classes abstraites peuvent-elles être utilisées à la place des interfaces? De plus, en tant que programmeurs, vous devez souvent entendre l'expression "programmation orientée vers l'interface", alors qu'est-ce que cela signifie? Quelle est la connotation idéologique? Quelle est la relation avec la programmation orientée objet? Cet article répondra à ces questions une par une.
1. Quelle est la relation entre la programmation orientée vers l'interface et la programmation orientée objet
Tout d'abord, la programmation orientée vers l'interface et la programmation orientée objet ne sont pas horizontales. Ce n'est pas une idée de programmation indépendante qui est plus avancée que la programmation orientée objet, mais qui est attachée au système de pensée orienté objet et appartient à sa partie. En d'autres termes, c'est l'essence de la pensée dans les systèmes de programmation orientés objet.
2. La nature de l'interface
Une interface est une composition ostensiblement composée de plusieurs définitions de méthode sans code corporel. Il a un nom unique et peut être implémenté par une classe ou une autre interface (ou peut également être considéré comme hérité). Cela peut ressembler à la forme suivante:
interface interfacename {void method1 (); VOID Method2 (int Para1); void Method3 (String Para2, String Para3); }Alors, quelle est l'essence d'une interface? Ou quelle est la signification de l'existence d'une interface? Je pense que cela peut être pris en compte dans les deux perspectives suivantes:
1) Une interface est un ensemble de règles qui spécifient un ensemble de règles qu'une classe ou une interface qui implémente cette interface doit avoir. Il incarne le concept de la nature que "si vous êtes ... vous devez pouvoir ..."
Par exemple, dans la nature, les gens peuvent manger, c'est-à-dire "si vous êtes humain, vous devez pouvoir manger". Ensuite, lorsqu'il est simulé dans un programme informatique, il devrait y avoir une interface Iperson (personnalisé, le nom de l'interface commence par "i"), et il existe une méthode appelée Eat (). Ensuite, nous stipulons que chaque classe représentant "humain" doit implémenter l'interface Iperson, qui simule la règle naturelle de "Si vous êtes un humain, vous devez être capable de manger".
De là, je pense que vous pouvez également voir des idées orientées objet. L'un des noyaux de la pensée orientée objet est de simuler le monde réel et de résumer les choses dans le monde réel en catégories. L'ensemble du programme s'appuie sur des cas de différents types pour communiquer entre eux et coopérer les uns avec les autres pour remplir les fonctions du système. Cela est très cohérent avec les conditions de fonctionnement du monde réel et est également l'essence de la pensée orientée objet.
2) Les interfaces sont des représentations abstraites de choses similaires sur une certaine vue granulaire. Notez que ici, je souligne sur une certaine vision granulaire, car le concept de «même chose» est relatif, et il varie en raison de différentes vues granulaires.
Par exemple, à mes yeux, je suis une personne, et il y a une différence fondamentale entre moi et un cochon. Je peux accepter la déclaration selon laquelle mes camarades de classe et moi sommes les mêmes, mais je ne dois pas accepter que je suis la même chose qu'un cochon. Cependant, si les yeux d'un zoologiste sont comme des porcs, je devrais être le même, parce que nous sommes tous les deux des animaux, il peut penser que "humain" et "cochon" ont mis en œuvre l'interface ianimale. Lorsqu'il étudie le comportement des animaux, il ne me traitera pas et les porcs séparément, mais l'étudiera à partir de la plus grande taille de particules de "l'animal", mais il pense qu'il y a une différence essentielle entre moi et un arbre.
Maintenant que j'ai changé pour un généticien, la situation est différente. Parce que tous les êtres vivants peuvent être hérités, à ses yeux, je ne suis pas seulement différent des cochons, mais aussi d'un moustique, d'une bactérie, d'un arbre, d'un champignon ou même d'un virus SRAS, parce qu'il pense que nous avons tous mis en œuvre l'interface idensable (note: descendance vi. Inhéritation), c'est-à-dire que nous sommes toutes ses choses. Il ne nous étudiera pas séparément, mais étudiera tous les êtres vivants comme des types similaires. À ses yeux, il n'y a pas de différence entre les humains et les virus, uniquement des substances héréditaires et des substances non héréditaires. Mais au moins, il y a toujours une différence entre moi et une pierre.
Mais malheureusement, un jour, un grand homme est apparu sur la terre, nommé Lénine. Après avoir été familier avec le chef-d'œuvre du matérialisme dialectique de Max et Engels, il avait beaucoup d'expérience, il a donc donné une définition célèbre: la soi-disant matière est une réalité objective qui peut être reflétée par la conscience. À ce stade, je ne suis plus différent d'une pierre, d'une trace d'air, d'un idiome et du champ électromagnétique qui transmet des signaux de téléphone mobile, car aux yeux de Lénine, nous sommes tous une réalité objective qui peut être reflétée par la conscience. Si Lénine était programmeur, il dirait ceci: la soi-disant affaire est les instances générées par toutes les classes qui implémentent les deux interfaces "ireflectabe" et "iesse". (Remarque: Réfléchissez v. Reflect Esse n. Réalité objective)
Peut-être que vous penserez que mon exemple ci-dessus est un non-sens, mais c'est exactement le sens de l'interface. L'une des idées et le noyau orientés objet est le polymorphisme. Qu'est-ce que le polymorphisme? Pour le dire franchement, il s'agit de traiter des choses similaires sans discrimination à un certain niveau de vue granulaire et de les gérer uniformément. Et la raison pour laquelle j'ose le faire est parce qu'il y a une interface. Comme ce généticien, il a compris que tous les organismes ont mis en œuvre l'interface idEscriptable. Tant qu'ils sont des organismes, il doit y avoir la méthode descendante (), afin qu'il puisse les étudier de manière unifiée sans étudier chaque organisme séparément et éventuellement épuisant.
Peut-être que nous ne pouvons pas vous donner une impression intuitive de la nature et de la fonction de l'interface. Ensuite, dans les exemples suivants et l'analyse de plusieurs modèles de conception, vous ressentirez plus intuitivement la connotation de l'interface.
3. Résumé de programmation orientée vers l'interface
Grâce à l'article ci-dessus, je pense que vous avez une compréhension de la connotation idéologique des interfaces et des interfaces. Alors, qu'est-ce que la programmation orientée vers l'interface? Ma définition personnelle est: dans l'analyse et l'architecture du système, nous distinguons les hiérarchies et les dépendances. Chaque niveau ne fournit pas directement des services à sa couche supérieure (c'est-à-dire non directement instanciée dans la couche supérieure), mais définit plutôt un ensemble d'interfaces, exposant uniquement ses fonctions d'interface à la couche supérieure. La couche supérieure ne dépend que de la couche inférieure et ne s'appuie pas sur des classes spécifiques.
Les avantages de cela sont évidents, et tout d'abord, il est très bénéfique pour la flexibilité du système. Lorsque la couche inférieure doit être modifiée, tant que les fonctions d'interface et d'interface restent inchangées, la couche supérieure n'a pas besoin de modifier les modifications. Vous pouvez même remplacer la couche inférieure sans modifier le code de la couche supérieure, tout comme nous remplaçons un disque dur WD 60G par un disque dur de Seagate 160G. Il n'est pas nécessaire d'apporter des modifications dans d'autres parties de l'ordinateur, mais débranchez simplement le disque dur d'origine et branchez le nouveau disque dur, car les autres parties de l'ordinateur ne dépendent pas du disque dur spécifique, mais ne s'appuient que sur une interface IDE. Tant que le disque dur implémente cette interface, elle peut être remplacée. De là, l'interface du programme est très similaire à l'interface en réalité, donc j'ai toujours cru que l'interface du mot est vraiment similaire!
Un autre avantage de l'utilisation d'interfaces est que les développeurs de différents composants ou niveaux peuvent commencer la construction en parallèle, tout comme ceux qui construisent des disques durs n'ont pas besoin de faire des processeurs ou des moniteurs. Tant que les interfaces sont cohérentes et que la conception est raisonnable, le développement peut être effectué en parallèle, améliorant ainsi l'efficacité.
Cet article viendra ici en premier. Enfin, je voudrais dire autre chose: l'essence de l'objet est de simuler la réalité, qui peut également être considérée comme l'âme de mon article. Par conséquent, réfléchir davantage aux choses orientées objet de la réalité sera très avantageuse à améliorer l'analyse du système et les capacités de conception.
Dans le prochain article, j'utiliserai un exemple pour afficher les méthodes de base de la programmation d'interface.
Dans le troisième article, je vais analyser certaines idées de programmation orientées vers l'interface dans le modèle de conception classique et analyser les idées axées sur l'interface dans l'architecture hiérarchique .NET.
Supplément à cet article:
Après avoir soigneusement lu vos réponses, je suis très heureux de discuter des problèmes techniques avec vous. Merci à vos amis qui ont donné l'affirmation, ainsi qu'à vos amis qui ont proposé des opinions et des questions, ce qui m'a incité à réfléchir plus profondément à quelque chose et à espérer progresser à travers cela. Ici, je voudrais ajouter quelque chose pour discuter de certains des problèmes les plus concentrés dans les réponses.
1. Concernant les deux mots "interface" dans "Programmation orientée vers l'interface" et le langage spécifique orienté objet "interface"
J'ai vu un ami suggérant que le mot «interface» dans la «programmation orientée vers l'interface» devrait avoir une plage plus grande que l'interface dans un langage de programmation simple. Après y avoir pensé, j'ai pensé que cela avait du sens. Ce que j'ai écrit ici est en effet déraisonnable. Je pense que "l'interface" dans le langage orienté objet fait référence à une structure de code spécifique, comme une interface définie en C # avec le mot-clé d'interface. L'interface "dans la" programmation orientée vers l'interface "peut être considérée comme un composant structurel qui se réfère à un niveau plus abstrait du point de vue de l'architecture logicielle et d'un niveau plus abstrait. En ce sens, si une classe abstraite est définie et que le but est d'atteindre le polymorphisme, alors je pense qu'il est raisonnable d'appeler cette classe abstraite également "interface". Mais est-il raisonnable d'utiliser des classes abstraites pour mettre en œuvre le polymorphisme? Discutez dans le deuxième article ci-dessous.
En résumé, je pense que les concepts de deux "interfaces" sont à la fois différents et liés les uns aux autres. Les interfaces dans la "programmation orientée vers l'interface" sont des composants architecturaux au niveau idéologique pour réaliser le polymorphisme, améliorer la flexibilité des logiciels et la maintenabilité, tandis que "les interfaces" dans des langages spécifiques sont les moyens d'implémenter les composants de cette idée en code.
2. À propos des classes et des interfaces abstraites
J'ai vu que c'était un problème plus intense dans la réponse. Désolé, je ne pensais pas bien à cette question dans l'article. Ma compréhension personnelle de cette question est la suivante:
Si nous regardons le code spécifique seul, ces deux concepts sont faciles à être floues, et nous pensons même que l'interface est redondante, car à partir de la fonction spécifique, à l'exception de l'héritage multiple (C #, en java), les classes abstraites semblent être en mesure de remplacer complètement les interfaces. Cependant, l'existence d'interfaces est-elle pour atteindre l'héritage multiple? Bien sûr que non. Je pense que la différence entre les classes abstraites et les interfaces est la motivation à utiliser. L'utilisation de classes abstraites est pour la réutilisation du code, tandis que la motivation pour l'utilisation d'interfaces est pour le polymorphisme. Donc, si vous hésitez à utiliser une interface ou une classe abstraite quelque part, vous pouvez penser à votre motivation.
En voyant les doutes d'un ami sur l'interface Iperson, ma compréhension personnelle est que la définition de l'interface Iperson dépend de l'application spécifique. S'il y a des femmes et de l'homme dans notre projet, à la fois une personne héritée, et que la plupart des méthodes des femmes et de l'homme sont les mêmes, et qu'il n'y a qu'une seule méthode, DosomethingInwc () est différente (l'exemple est vulgaire, veuillez me pardonner), puis bien sûr, il est plus raisonnable de définir unique code.
Cependant, si les classes des femmes et des hommes de notre programme n'ont essentiellement pas de code commun, et qu'il y a une classe PersonHandle qui doit les instancier, et ne veulent pas savoir si ce sont des hommes ou des femmes, mais les traiter simplement comme des humains et mettre en œuvre le polymorphisme, alors il faut les définir comme des interfaces.
En bref, la différence entre une interface et une classe abstraite est principalement due à la motivation d'utilisation, pas à elle-même. Lorsqu'une chose doit être définie comme une classe abstraite ou une interface, elle doit être déterminée en fonction du contexte de l'environnement spécifique.
De plus, je pense que une autre différence entre une interface et une classe abstraite est qu'il devrait y avoir une relation générale et spéciale entre une classe abstraite et sa sous-classe, tandis qu'une interface n'est qu'un ensemble de règles que sa sous-classe devrait mettre en œuvre. (Bien sûr, il peut y avoir une relation générale et spéciale, mais le but de notre utilisation des interfaces n'est pas là.) Par exemple, il est acceptable de définir les véhicules comme des classes abstraites et des voitures, des avions et des navires comme sous-classes, car les voitures, les avions et les navires sont tous des véhicules spéciaux. Par exemple, l'interface icomparable indique simplement que les classes qui implémentent cette interface doivent être comparées, ce qui est une règle. Si la classe de voiture implémente iCompparable, cela signifie simplement qu'il existe un moyen dans notre voiture de comparer deux instances de voiture, qui peuvent être plus chères que la voiture ou la plus grande que la voiture. Cela n'a pas d'importance, mais nous ne pouvons pas dire que "les voitures sont spéciales et peuvent être comparées", qui n'est pas grammaticalement applicable.
J'espère que cet article sera utile à la programmation Java de tous.