Je me demande si quelqu'un peut vous conseiller sur de bons moyens de rompre une dépendance circulaire entre 2 classes en Java! FindBugs propose l'utilisation d'interfaces alors je me demande si quelqu'un a une bonne expérience avec ce type de problème!Faire face à une dépendance circulaire
Merci d'avance!
Proposer une lecture du principe d'inversion de dépendance, par ex. What is the Dependency Inversion Principle and why is it important? ou http://en.wikipedia.org/wiki/Dependency_inversion_principle
Downvoter-- pourquoi? – andersoj
Probablement à cause du contexte manquant autour de vos URL liées. Les URL sont encouragées pour une lecture ultérieure, mais la réponse doit contenir un certain contexte et l'essence des URL. S'il vous plaît voir ceci: http://stackoverflow.com/help/how-to-answer (Fournir un contexte pour les liens) – sceiler
Il y a un billet de blog here sur la façon dont Restructure101 a été utilisé pour supprimer les dépendances cycliques, « enchevêtrements », de Junit et presentation de Lausanne JUG sur la façon dont il a été utilisé pour enlever les enchevêtrements de Icefaces. En ce qui concerne le débat sur la question de savoir si les dépendances cycliques sont mauvaises, je suggère de lire Solid Principles de Uncle Bob.
Avis de non-responsabilité: Je travaille pour Headway Software, les développeurs de Restructure101.
Les dépendances circulaires ne doivent pas toujours être évitées. Je les éviterais dans le grand, mais garde dans les petits coins serrés d'un système. En gros, si la couche d'accès aux données et la couche de représentation de l'application J2EE sont dépendantes, je dirais que c'est une mauvaise chose, car cela signifie que tout doit être compilé en une seule fois et que le test est cauchemardesque. Mais, ce n'est pas un problème si une structure de données de liste et son type d'itérateur sont des dépendances circulaires. Comme Findbugs suggère d'utiliser des interfaces pour rompre une dépendance circulaire. I.e introduit une interface pour au moins un type de cercle et fait que les autres classes utilisent l'interface partout. Avez-vous besoin d'un exemple de code?
+1. Les bonnes méthodologies de conception sont bonnes en vertu d'un avantage évident. Dans les circonstances spécifiques d'une collection et de son itérateur (paresseux) par exemple, l'introduction d'une nouvelle interface simplement pour rompre le cycle est exagérée. Cependant, je dirais ceci: n'utilisez que des dépendances circulaires dans des circonstances où vous pouvez inclure toutes les dépendances sauf une en tant que classes internes ou imbriquées. En fait, en utilisant les classes internes de cette manière, vous pouvez éviter de nombreuses alertes de dépendances circulaires, en utilisant la référence de conteneur implicite que conserve la classe interne. –
En utilisant la référence implicite des classes internes, vous risquez d'éviter les avertissements d'outils, mais votre code contient toujours des références circulaires. Mais comme je l'ai dit, je conseillerais de rendre les cercles aussi petits que possible - ne pas les éviter à tout prix. Et en utilisant des classes internes, vous faites cela. – jmg
Quel est le problème avec les références circulaires en premier lieu? Pourquoi voudriez-vous les casser? Peut-être devriez-vous le signaler dans votre question. – Mecki
bien, je ne sais pas ... supposer est un anti-modèle que je veux éviter! et à des fins éducatives, pour vérifier les différentes possibilités de conception.! – tropicana
Refs circulaires sont un anti-modèle? Dit qui? Le GC Java n'a aucun problème avec eux pour les instances (seulement un GC qui utilise le comptage de référence pur aurait un tel problème) et le compilateur n'a aucun problème avec eux au moment de la compilation, à part que vous devez compiler les deux classes en même temps, donc le compilateur est capable de résoudre les dépendances. BTW, vous avez manqué un tag important: java. Je vais réparer les tags pour vous. – Mecki