Ich verwende die Sonar-Code-Qualitätsverwaltungsplattform seit einiger Zeit, und in den meisten Fällen finde ich es sehr hilfreich, versteckte Designfehler meiner Code-Basis aufzudecken.
Allerdings gibt es eine Regel, die mir mehr Ärger bereitet als Hilfe und das ist die Überprüfung auf Verletzungen des zyklischen Paketverweises.
Ich glaube, ich verstehe völlig, wo eine solche Abhängigkeit zwischen Pacakges eine schlechte Sache ist. Zum Beispiel ist es in einem typischen dreistufigen Darstellungs / Dienst / Persistenz-Schichten-Design fast immer eine schlechte Idee, den Datenbankbehandlungscode einen Verweis zurück zu UI-bezogenen Klassen zu haben. Ich habe kein Problem damit, es als "Verstoß" zu bezeichnen.
Aber betrachten wir andere Fälle, d. h. wie das Entwerfen einer IDE-ähnlichen Anwendung. Nehmen wir an, wir haben ein Hauptpaket, das eine Application -Schnittstelle enthält, die List Application.getViews () -Methode definiert, um auf Anwendungsansichten zu verweisen.
Wenn jedoch die View -Schnittstelle über eine Application getApplication () -Methode verfügt, die auf ihre ursprüngliche Anwendung verweist, was meiner Meinung nach ein ziemlich übliches Design ist, wird sie eingeführt eine zyklische Referenz, sofern die einzelnen Schnittstellen in com.myapp.ui bzw. com.myapp.ui.view getrennt sind.
Natürlich können Sie einfach die Ansicht -Schnittstelle in die com.myapp.ui einfügen, um den Zyklus zu unterbrechen. Aber wenn Sie verschiedene andere View-bezogene APIS in com.myapp.ui.view haben, viele von ihnen eine andere abstrakte APIs wie AbstractView , ContentView , AbstractContentView usw. Ich frage mich, ob es besser ist, sie für einen Verwaltungszweck in separaten Paketen zu speichern.
Und bedenke, dass die genannte Anwendung viele andere ähnliche Fälle hat, wie com.myapp.ui.action , com.myapp.ui.perspective usw., die wirklich funktionieren würden com.myapp.ui pacakge überfüllt, wenn wir sie alle dort hineinlegen sollen.
Also, welchen Ansatz schlagen Sie vor, um mit einer solchen Situation umzugehen? Sind wirklich alle zyklischen Pakete eine schlechte Sache? Oder wenn ich mit ihnen leben muss, wie konfiguriere ich Sonar, um nur echte, problematische Zyklen zu überprüfen?
Danke!
Jedes Absolute - außer diesem; - wird manchmal falsch sein. Also, ist jede zyklische Referenz schlecht? Nein. Sie müssen Ihr Urteilsvermögen verwenden.
Aber wenn Sie eine zyklische Abhängigkeit einführen, lohnt es sich zu fragen, ob Sie es wirklich brauchen und warum. Der tl; dr ist das mehr als oft nicht, Sie können feststellen, dass das Durchbrechen des Zyklus Ihre Modularität verbessern kann und insbesondere Ihre Fähigkeit, Komponenten separat zu testen.
Benötigen Sie für Ihr Beispiel wirklich eine getApplication() , die vermutlich ein relativ "schweres" Objekt zurückgibt (dh eines, das selbst eine Datenbank, ein Netzwerk usw. benötigt)? Vielleicht ... aber vielleicht nicht. Wenn das, was Sie wirklich von diesem getApplication benötigen, etwas mit ein paar Callbacks ist (wie wenn ein Benutzer eine Aktion initiiert), dann könnte es nützlich sein, eine Schnittstelle in einem gemeinsamen Paket für diesen Callback zu erstellen. Also, anstatt:
Sie hätten:
%Vor%Die Frage, die Sie stellen sollten, lautet: Was gibt mir das? Es könnte sein, dass du so viel ausstechen musst, dass es dir nicht viel gibt - obwohl das vielleicht nahelegt, dass du deinen Unterricht etwas zerlegen kannst. Aber es könnte sein, dass es tatsächlich einfacher macht, Ihre Ansicht zu testen, denn jetzt kann Ihr Komponententest (1) die Ansicht testen, ohne eine ganze Anwendung hochzufahren, und (b) einen "Dummy" -Rückruf bereitstellen, der etwas wie das Speichern eines Zeichenfolge, die die Aktion beschreibt, und dann bestätigt Ihr Komponententest, dass es die richtige Zeichenfolge gespeichert hat.
Und tatsächlich gibt es ein offenes JIRA-Ticket, um zu verhindern, dass ein Zyklus zwischen Vater / Kind-Paketen als Qualitätsfehler betrachtet wird: Ссылка