Devrait interfaces être placé dans un emballage séparé?

Question

Je suis nouveau à une équipe travaillant sur un assez gros projet, avec beaucoup de composants, dépendances. Pour chaque composant, il y a un interfaces paquet, où les interfaces exposées= pour que le composant est placé. Est-ce une bonne pratique?

Ma pratique habituelle a toujours été interfaces et implémentations aller dans le même package.

Answer 1

Placer la fois l'interface et la mise en œuvre est un lieu commun, et ne semble pas être un problème.

Prenez l'exemple de l'API Java -- la plupart des classes sont les deux des interfaces et de leurs implémentations inclus dans le même package.

Prenez l'exemple de l' java.util paquet de:

Il contient les interfaces comme l' Set, Map, List, tout en ayant également la implémentations telles que l' HashSet, HashMap et ArrayList.

En outre, la documentation Javadoc sont conçus pour bien fonctionner dans ces conditions, qu'il sépare de la documentation sur les Interfaces et les Classes de vues lors de l'affichage du contenu de l'emballage.

Avoir des paquets uniquement pour les interfaces peuvent en fait être un peu excessif, à moins qu'il existe un très grand nombre d'interfaces. Mais séparer les interfaces dans leurs propres paquets juste pour le plaisir de faire des sons comme une mauvaise pratique.

Si la différenciation le nom d'une interface à partir d'une mise en œuvre est nécessaire, on pourrait avoir une convention de nommage pour rendre les interfaces plus facile à identifier:

• Préfixe le nom de l'interface avec un I. Cette approche est pris avec les interfaces de la .NET framework. Il serait assez facile de dire qu' IList est une interface pour une liste.

• Utiliser l' -able suffixe. Cette approche est vu souvent dans l'API Java, comme Comparable, Iterable, et Serializable pour n'en nommer que quelques-unes.

Answer 2

Pour toute langue, de les mettre ensemble dans le même emballage est très bien. L'important, c'est ce qui est exposé au monde extérieur, et à quoi ça ressemble de l'extérieur. Personne ne va savoir ou de soins, ou si la mise en œuvre est dans le même paquet ou non.

Regardons ce cas particulier.

Si vous avez tous les éléments dans un seul paquet, et privé les choses dans un autre package qui n'est pas exposé publiquement, le client de la bibliothèque en voit un paquet. Si vous déplacez le privé choses pour le paquet avec l'exposé publiquement les choses, mais ne les exposez pas à partir de l'intérieur du colis, le client voit exactement la même chose.

Ainsi, ce qui a l'odeur d'une règle avec aucune bonne raison: c'est de prendre une décision basée sur quelque chose de visible publiquement, sans que la décision ayant une incidence sur ce qui est visible publiquement.

Answer 3

Dans de nombreux cadres, comme OSGi, vous presque. Je pense que cela favorise un couplage lâche, à l'emballage au lieu du pot.

Answer 4

Un argument pour mettre interfaces dans les différents paquets, c'est qu'il est plus facile de créer des " api " pots qui peuvent être distribués aux consommateurs de votre produit ou service. Il est parfaitement possible de le faire avec des interfaces et implémentations ensemble, mais c'est plus simple script s'ils sont dans différents paquets.

Answer 5

Nous le faisons, où je travaille (c'est à dire: mettre de l'interface dans un seul paquet et la mise en œuvre dans un autre), et le principal avantage de nous sortir de cette situation est que nous pouvons permuter facilement entre les implémentations.