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. P>
4 Réponses :
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. P>
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.
IMHO, comme @HARSHA mentionné dans le commentaire existant, la solution la plus simple consisterait à placer le code partagé dans une bibliothèque Vous avez maintenant une API précieuse qui peut être maintenue facilement pour chaque construction avec vos versions. P>
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. P>
Y a-t-il des exceptions communes en commun? Ça semble bizarre. P>
Y a-t-il une dépendance entre ces projets? Est l'un est le client d'autre? P>
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. P>
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 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. P> super code>, ils semblent être les mêmes. P >
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.
Je les garderais dans un pot séparé et combinerais le pot avec les deux projets après la construction.