7
votes

Où devraient-ils être exceptionnels utilisés par plusieurs projets?

Je dois refactuer un projet avec deux modèles de données en deux projets distincts. Les deux projets utilisent les mêmes exceptions. Devrais-je créer un 3ème projet uniquement pour ces exceptions? Le clonage sonne comme un non-go.


1 commentaires

Je les garderais dans un pot séparé et combinerais le pot avec les deux projets après la construction.


4 Réponses :


7
votes

Oui, vous devez le créer sur un projet séparé et l'utiliser comme une dépendance sur les autres. Il n'est pas rare de voir un projet / pot qui n'a que les exceptions utilisées dans les modules que vous travaillez. C'est une bonne façon de garder les choses organisées imho.


2 commentaires

Non accepté, avoir seulement des exceptions communes entre deux projets me semble malodorant. Je crois qu'ils sont la même chose dans leurs noms de classe et rien de plus!


Je pense que OP signifie 2 modules dans le même projet, pas en réalité 2 projets indépendants. Si tel est le cas, cette solution ainsi que cette question n'a aucun sens. Même les noms de colis seraient étranges.



1
votes

IMHO, comme @HARSHA mentionné dans le commentaire existant, la solution la plus simple consisterait à placer le code partagé dans une bibliothèque bibliothèque ou fichier .jar et le fichier .jar à votre bibliothèque de projet.

Vous avez maintenant une API précieuse qui peut être maintenue facilement pour chaque construction avec vos versions.


0 commentaires

1
votes

Un projet séparé qui est une dépendance partagée des deux autres est probablement le meilleur. La duplication des objets rendrait les choses difficiles si les deux modèles de données sont utilisés ensemble, que vous devriez résoudre via E.G. Différents noms de paquet et qui créeraient des maux de tête de maintenance. Le projet partagé peut être un bon référentiel pour le futur code partagé au-delà de vos exceptions.


0 commentaires

1
votes

Y a-t-il des exceptions communes en commun? Ça semble bizarre.

Y a-t-il une dépendance entre ces projets? Est l'un est le client d'autre?

Je pense qu'il y aura également des interfaces en commun aussi, certaines déclarent ces exceptions dans leur signature de méthodes. Certains qui sont mis en œuvre dans l'un de vos projets et sont appelés dans d'autres projets.

S'il n'y a pas de telle chose, il semble que vos préceptes communes sont simplement en commun par leurs noms! Ce ne sont pas vraiment les mêmes classes, ils ont juste le même nom et, car de nombreuses exceptions définies par l'utilisateur ne sont que des constructeurs qui appellent des constructeurs super , ils semblent être les mêmes.

Si c'est votre cas, je ne me dérangerais pas à extraire les classes et que je tiendrais les duplications, car il n'y a rien gagné par le refactoring.


1 commentaires

Ce sont deux modèles pour deux systèmes (en fait plus) différents systèmes utilisés pour importer des données dans un système cible. Il y a plus de choses en commun que j'ai déjà mis dans un projet UTIL. Mais je ne pense pas que les exceptions devraient y aller, car un seul système pourrait ne pas avoir besoin des utils, mais les exceptions.