Interfaces Java / Convention de dénomination d'implémentation

Question

Double Possible:
Interface de nommage en Java

Comment faites-vous le nom des différentes classes / interfaces-vous créer? Parfois, je n'ai pas la mise en œuvre de l'information à ajouter à la mise en œuvre de nom - comme l'interface FileHandler et la classe SqlFileHandler.

Lorsque cela arrive, j'ai l'habitude de nom de l'interface dans le nom "normal", comme Truck et le nom de la classe réelle TruckClass.

Comment faites-vous le nom des interfaces et des classes à cet égard?

Answer 1

Nom de votre Interface ce qu'il est. Truck. Pas ITruck car il n'est pas un ITruck c'est Truck. Un Interface en Java est un Type. Ensuite, vous avez DumpTruck, TransferTruck, WreckerTruck, CementTruck, etc. Lorsque vous utilisez l' Interface Truck à la place d'une sous-classe que vous venez de convertir Truck. Comme en List<Truck>. Mettre I devant est juste de la merde à la hongroise, la notation de la tautologie qui n'ajoute rien, mais plus de choses à type de votre code.

Tous les IDE Java de la marque Interfaces et Implémentations et ce n'est pas sans ce stupide notation. Ne l'appelez pas TruckClass qui est la tautologie tout aussi mauvais que l' IInterface de la tautologie.

Si c'est une mise en œuvre il s'agit d'une classe. La seule véritable exception à cette règle, et il y a toujours des exceptions est - AbstractTruck. Puisque seuls les sous-classes de tous les voir, et vous ne devriez jamais jeté un Abstract classe il n'ajouter quelques informations que la classe est abstraite et à la façon dont il doit être utilisé. Vous pouvez toujours venir avec un meilleur nom que AbstractTruck et l'utilisation BaseTruck à la place. Mais depuis Abstract classes ne devrait jamais faire partie de tout public en face de l'interface, il est acceptable d'exception à la règle. Faire les constructeurs protected va un long chemin pour traverser ce fossé.

Et l' Impl suffixe est juste plus de bruit. Plus de la tautologie. Tout ce qui n'est pas une interface est une mise en œuvre, même les classes abstraites qui sont partielle des implémentations. Allez-vous mettre ce stupide Impl suffixe sur chaque nom de chaque Classe?

L' Interface est un contrat sur ce que le public des méthodes et des propriétés à l'appui, c'est aussi le Type d'information. Tout ce qui implémente Truck est un Type d' Truck.

Look de la Java standard de la bibliothèque elle-même. Voyez-vous IList, ArrayListImpl, LinkedListImpl? Ne voyez-vous. List et ArrayList et LinkedList. Voici un bel article à propos de cette question exacte. L'un de ces stupides préfixe/suffixe conventions de nommage de tous les violer le SEC principal.

Aussi, si vous trouvez l'ajout d' DTO, JDO, BEAN ou autre idiot répétitif des suffixes pour les objets, puis ils appartiennent probablement à un paquet à la place de tous ces suffixes. Correctement emballé, les espaces de noms sont auto de la documentation et de réduire tout ce qui est inutile, la redondance de l'information dans ces vraiment mal conçu propriétaire schémas de nommage que la plupart des endroits ne sont même pas en interne respecter de manière cohérente.

Si tout ce que vous pouvez venir avec pour faire de votre Class nom unique est suffixant il avec Impl, alors vous avez besoin de repenser avoir un Interface . Alors, quand vous avez une situation où vous avez un Interface et un seul Implementation qui n'est pas uniquement spécialisé de l' Interface vous n'avez probablement pas besoin de l' Interface.

Answer 2

J'ai vu des réponses ici que suggèrent que si vous avez seulement une mise en œuvre, alors vous n'avez pas besoin d'une interface. Cela va à l'encontre de l'Injection des Dépendances/Inversion de Contrôle principe ("ne nous appelez pas, nous vous appellerons pour vous!).

Donc oui, il y a des situations dans lesquelles vous souhaitez simplifier votre code et de le rendre facilement testable en s'appuyant sur les injecté des implémentations d'interface (qui peut aussi être mandaté - votre code ne le sait pas!). Même si vous avez seulement deux implémentations, l'un d'une Maquette pour le test, et qui est injecté dans le code de production - ce n'est pas d'avoir une interface superflu. Une bien documenté interface établit un contrat, qui peut être maintenu par une stricte se moquer de mise en œuvre pour les tests.

en fait, vous pouvez établir des tests qui ont se moque de mettre en œuvre le plus strict de l'interface de contrat (lancer des exceptions pour des arguments qui ne devraient pas être null, etc) et de capture des erreurs dans les tests, à l'aide d'une application plus efficace dans la production de code (pas de vérification des arguments qui ne devraient pas être null pour les nul depuis la maquette a jeté des exceptions dans vos tests et vous savez que les arguments ne sont pas nulles en raison de la fixation du code après ces tests, par exemple).

L'Injection de dépendances/CIO peut être difficile à appréhender pour un débutant, mais une fois que vous comprenez son potentiel que vous aurez envie de l'utiliser tous sur la place et vous trouverez vous-même de faire des interfaces tout le temps - même si il n'y aura qu'un (production réelle) de la mise en œuvre.

Pour cette mise en œuvre (vous pouvez déduire, et vous seriez correct, que je crois que l'on se moque de contrôle doit être appelé Maquette(Nom_interface)), je préfère le nom par Défaut(Nom_interface). Si un plus spécifiques d'application de la vient le long, il peut être nommé de façon appropriée. Cela évite également les Impl suffixe que je n'aime pas (si ce n'est pas une classe abstraite, c'est ÉVIDEMMENT un "impl"!).

Je préfère aussi "de Base(Nom_interface)" par opposition à "Abstrait(Nom_interface)" parce qu'il y a certaines situations dans lesquelles vous voulez que votre classe de base pour devenir instanciables plus tard, mais maintenant vous êtes coincé avec le nom "Abstrait(Nom_interface)", et cela vous oblige à renommer la classe, ce qui pourrait causer un peu mineur de la confusion - mais si c'était toujours de la Base(Nom_interface), suppression de l'abstrait modificateur ne change pas ce que la classe a été.

Answer 3

Le nom de l'interface doit décrire le concept abstrait représenté par l'interface. Toute classe d'implémentation doit avoir des caractéristiques spécifiques qui peuvent être utilisées pour lui donner un nom plus spécifique.

S'il n'y a qu'une seule classe d'implémentation et que vous ne pouvez pas penser à quelque chose qui le rende spécifique (impliqué en voulant le nommer -Impl ), alors il semble qu'il n'y ait aucune justification pour avoir une interface.

Answer 4

J'ai tendance à suivre les pseudo-conventions établies par Java Core/Soleil, par exemple dans les Collections de classes:

• List - interface pour le "conceptuel" de l'objet
• ArrayList - la mise en œuvre concrète de l'interface
• LinkedList - la mise en œuvre concrète de l'interface
• AbstractList - abstrait "partielle" de la mise en œuvre d'aider des implémentations personnalisées

J'ai utilisé pour faire la même chose modélisation de mes classes d'événements après l'AWT Événement/Auditeur/Adaptateur de paradigme.

Answer 5

La convention C # standard, qui fonctionne aussi bien en Java, consiste à préfixer toutes les interfaces avec un I - donc votre interface de gestionnaire de fichiers sera IFileHandler et votre interface de camion sera ITruck . C'est cohérent, et il est facile de distinguer les interfaces des classes.