La programmation par rapport aux interfaces en Java est-elle la même chose que l’utilisation de fichiers d’en-tête en C / C ++?

Le code Java sur lequel je travaille en ce moment a souvent une structure comme

fichier Controller.java:

interface Controller {...} 

Fichier ControllerImpl.java:

 class ControllerImpl implements Controller {...} 

Mais pour chaque interface, il n’y a qu’une seule implémentation. N’est-ce pas la même chose que d’utiliser des fichiers d’en-tête en C / C ++ où j’ai le code divisé en fichiers comme

 Controller.hpp Controller.cpp 

D’après ce que je sais, des fichiers d’en-tête en C / C ++ ont été introduits pour aider le compilateur, ce qui n’est plus nécessaire en Java. Les fichiers d’en-tête devraient également aider à la lisibilité du code, mais disposer d’un IDE moderne avec repliement et vue d’ensemble n’est plus une nécessité.

Alors, pourquoi les gens introduisent-ils à nouveau les fichiers d’en-tête en Java par la porte arrière en programmant des interfaces?

Non. En C ++, les fichiers (en-têtes) ne sont pas identiques aux classes.

La programmation sur les interfaces, comme en Java, peut également être réalisée en C ++, en programmant sur des classes de base abstraites .

Cependant, le terme Java “interface” est assez restreint. Fondamentalement, toute déclaration de fonction est une interface:

 void call_me(int times); 

Comme sont, bien sûr, les classes et autres types.

En C ++, vous regroupez ces éléments dans des en-têtes. Ainsi, une interface peut être composée d’un en-tête. Cependant, il pourrait tout aussi bien se composer de plusieurs en-têtes.

Les interfaces ne proviennent pas d’une volonté de conserver des fichiers d’en-tête.

Interfaces sockets en charge par Java le plus proche http://en.wikipedia.org/wiki/Design_by_contract

les interfaces ressemblent davantage à des classes de base abstraites en c ++.

La raison pour laquelle ils sont souvent utilisés en Java est que l’inheritance multiple n’existe pas en Java (les deux étaient des décisions de conception). c ++ supporte l’inheritance multiple, donc … il peut résoudre le problème de cette façon (et via quelques autres).

Une fois qu’une classe implémente une interface en Java, elle peut alors être transmise comme type. Même principe en c ++, bien que l’implémentation écrite soit légèrement différente.

ainsi, l’interface simplifie le processus de programmation, car des objects arbitraires peuvent être passés tant qu’ils implémentent l’interface (ou en c ++ sont dérivés d’une classe spécifique). avec une interface, vous n’avez pas besoin de dériver d’une classe de base commune – c’est une conception très simple et utilisable. l’inheritance multiple en c ++ est un écueil pour de nombreux développeurs.

En Java, une interface définit un contrat , tandis qu’une classe fournit une implémentation d’un contrat.

La plupart des contrats n’ont qu’une seule mise en œuvre significative ou pertinente; certains supposent même une implémentation spécifique et n’en permettent aucune autre. Ces contrats et leurs implémentations sont définis ensemble dans des classes, sans aucune interface. Exemple: java.lang.Ssortingng .

Par contre, certains contrats ne font aucune hypothèse sur les implémentations possibles. Ceux-ci sont définis dans les interfaces. Les implémentations partielles peuvent être définies dans des classes abstraites et les implémentations complètes typiques peuvent être définies dans des classes, mais le fait que le contrat soit défini dans une interface vous permet d’écrire votre propre implémentation de ce contrat et de l’utiliser n’importe où une instance du contrat est attendu.

Au niveau du fichier, une interface et une classe sont des unités de compilation et méritent leur propre fichier.

Comme vous le comprenez maintenant, la distinction entre les fichiers d’en-tête et les fichiers d’implémentation en C ++ est très différente.

La question est bonne, il existe un lien entre les fichiers d’en-tête et la programmation des classes / interfaces / OO, au-delà de la syntaxe brute des langages.

Conception correcte du programme C ++:

  • Placez une déclaration de classe et une seule dans un fichier h.
  • Donnez à h-file le même nom que la classe déclarée.
  • Placez la définition de la classe dans un fichier cpp portant le même nom que le fichier h.

Conception correcte du programme Java:

  • Identique à C ++, mais met également des interfaces dans des fichiers qui leur sont propres.

Bonne conception en C:

  • Dans le fichier h, déclarez les fonctions appartenant à un “module de code” particulier.
  • Placez les définitions de fonction dans un fichier c portant le même nom que le fichier h.
  • Toutes les variables que vous auriez déclarées privées / protégées si l’écriture en C ++ / Java devaient être soit vraiment privées à travers le concept de “type opaque / pointeurs”, soit être placées au niveau du fichier et déclarées statiques, de manière à pouvoir être partagées entre des fonctions dans le “module de code” (bien que cela rend le code non réentrant).

Si vous n’utilisez pas la connexion intime ci-dessus entre classes et fichiers h, il y a de bonnes chances que votre programme soit un désordre illisible, quelle que soit l’élégance de votre conception OO.

Non, la programmation par rapport aux interfaces n’a rien à voir avec l’utilisation ou non de fichiers d’en-tête.

Définir explicitement une interface permettra de faire évoluer le programme des deux côtés de manière indépendante. L’interface d’un corps de code désigne le contrat auquel il obéit.

Les langages de programmation ne supportent jamais complètement les définitions d’interface, ils ont simplement un sucre syntaxique pour gérer l’aspect de correction de type. Les aspects de performance, par exemple, sont la plupart du temps indéterminés, tout comme les règles de complexité, etc. … (le standard C ++ définit certaines exigences de complexité pour les conteneurs et les algorithmes).

Cette prise en charge limitée a laissé Java avec le mot-clé interface : étant donné que l’orientation object concerne le regroupement de fonctionnalités dans des classes, il était logique de coupler le concept d’interface à quelque chose qui regroupe les définitions de fonctions membres. Plusieurs classes peuvent implémenter une interface donnée et une classe peut également implémenter de nombreuses interfaces.

En C ++, ils n’ont même pas pris la peine d’append explicitement “interface” au langage. La chose qui se rapproche le plus de l’interface de classe de Java est une classe abstraite pure: une classe avec uniquement des fonctions membres virtuelles pures. Comme C ++ prend en charge plusieurs inheritances, les classes peuvent implémenter plusieurs de ces “interfaces”.

S’agissant de la séparation de votre code en en-têtes et en fichiers sources, le concept d’interface est totalement dépourvu de pertinence. Mais effectivement: en C ++, le «contrat appelant» est principalement spécifié dans un fichier d’en-tête. Et en effet, cela réduit les temps de compilation (moins d’IO). Mais c’est un aspect technique du compilateur.

Les fichiers d’en-tête en C / C ++ n’ont absolument rien à voir avec les classes ou les interfaces.

Un fichier d’en-tête ressemble plus à la référence que vous ajoutez à votre projet ou à l’instruction using.

C’est une instruction pour le compilateur que les déclarations d’object et de fonction dans le fichier d’en-tête existent afin que le compilateur puisse comstackr le fichier sans avoir à parcourir l’ensemble du projet.

Un fichier d’en-tête en C ++ peut contenir des classes ou des définitions de fonction, des macros ou des énumérations ou de nombreuses autres choses, mais il est très différent conceptuellement des classes ou des interfaces.

Vous pouvez utiliser l’interface en C ++ pour Comment déclarer une interface en C ++? et ces définitions sont placées dans des fichiers d’en-tête, mais le fichier d’en-tête qu’il contient est autre chose.

La raison d’utiliser l’interface au lieu de l’inheritance est que de nombreuses classes peuvent implémenter une interface ou plusieurs interfaces, mais vous ne pouvez hériter que d’une classe.

Ainsi, si de nombreux objects doivent être interchangeables, vous obtiendrez une hiérarchie de classes très complexe, tandis qu’avec les interfaces, les classes pourront être construites de manière totalement séparée avec uniquement l’interface qui les relie.