2009-05-27 6 views
0

Im Java-Code für unsere Anwendung bin ich mir ziemlich sicher, dass es viele Klassen und Methoden gibt, die public Zugriff haben, aber wahrscheinlich nur Zugriff auf Paketebene benötigen.Gibt es ein Tool zum Analysieren der Zugriffsebene von Java-Klassen und -Methoden?

Was ich tun möchte, ist unseren Code auf einem Paket nach Paket-Ebene aufräumen, so dass nur Dinge, die wirklich außerhalb jedes Pakets public sichtbar machen müssen, da dies andere Refactoring vereinfachen soll, die ich tun möchte.

Ich frage mich, ob es ein Werkzeug zur Verfügung, die mir dabei helfen könnte. Idealerweise würde er den gesamten Code analysieren und einen Bericht erstellen, der angibt, welche Klassen und Methoden öffentlich zugänglich sind, aber nur innerhalb desselben Pakets aufgerufen werden.

Die Option Option in Netbeans kann mir dabei helfen, aber es für jede Klasse und Methode von Hand laufen und analysieren die Ausgabe Zeile für Zeile wird ewig dauern.

+0

Bezahlen Sie für solch ein Werkzeug? – zvikico

+0

@zvikico Ich könnte für Werkzeug bezahlen, aber im Idealfall wäre es kostenlos.Wenn es $ 30 wäre, könnte ich es wahrscheinlich bekommen gekauft für mich, wenn es $ 3.000 wahrscheinlich nicht ist. –

+0

Nur weil es einen anderen Zugriffsmodifikator haben könnte, heißt das nicht, dass es sollte. Ist das überhaupt etwas wert? – willcodejavaforfood

Antwort

3

Ich habe ProGuard, die Byte-Code-Manipulations-Tool, verwendet, um toten Code in der Vergangenheit zu finden. Es gibt ein Beispiel in der ProGuard manual, wie man es benutzt. Beachten Sie, dass das Tool auch viele andere Dinge tut und es ist nicht wirklich eine typische Verwendung davon, aber es ist das einzige, was ich weiß, dass eine ganze Anwendung für toten Code scannen kann.

Edit: Also habe ich die Frage falsch gelesen. Vielleicht ist UCDetector was Sie wollen. Es behauptet, in der Lage zu sein, "Code zu erkennen, wo die Sichtbarkeit geändert werden konnte zu geschützt, Standard oder privat. Es ist jedoch an Eclipse gebunden. Ich habe gerade versucht UCDetector auf meinem Code-Basis und es scheint den Job zu tun. Sicher entdeckt einige Methoden und Klassen, die ihre Sichtbarkeit verringert haben könnten.

+0

Der Code, den ich suche, ist nicht tot; nur mit dem falschen Zugriffslevel. Ich suche nach Methoden, die "public void foo()" sind, was "void foo()" sein könnte, keine Methoden, die ich komplett entfernen kann. –

+0

Ah, sorry, falsch gelesen Ihre Frage. Vielleicht http: // www.ucdetector.org/ ist was du willst. Es behauptet, in der Lage zu sein, "Code zu erkennen, bei dem die Sichtbarkeit in geschützt, Standard oder privat geändert werden könnte". Beachte, dass ich es nicht benutzt habe und es an Eclipse gebunden ist. – deverton

+0

Ich habe gerade versucht, UCDetector auf meinem Code-Basis und es scheint die Arbeit zu tun. Sicherlich wurden einige Methoden und Klassen entdeckt, die ihre Sichtbarkeit reduzieren könnten. – deverton

0

Die Netbeans SQE plugin kann helfen.

Es integriert FindBugs, PMD, CheckStyle und Lint4j in Netbeans. Dies sollte Warnungen bereitstellen, dass öffentliche Methoden als Paket private und ähnliche gemacht werden können.

+0

FindBugs, PMD, CheckStyle und Lint4j scheinen auf Klassenbasis zu funktionieren, anstatt die Anwendung als Ganzes zu betrachten, also glaube ich nicht, dass sie helfen werden. Sie sehen alle nützlich aus, aber keiner scheint nach dem speziellen Problem zu suchen, nach dem ich suche. Die SQE-Plugin enthält auch Dependency Finder, die vielversprechend aussieht, aber wieder zeigt mir Abhängigkeiten, scheint aber keine Ausnahme Bericht für eine zu große Zugriffsebene zu haben. –

1

die billige (und ziemlich wahrscheinlich schneller als ein Werkzeug für einen einzigen Durchgang der Installation) sind public class zu class und in ähnlicher Weise für abstract, final und interface zu suchen und zu ersetzen. Recompile. Fix was Pausen bis es kompiliert

+0

Dies könnte für Klassen aber nicht für Methoden funktionieren. Ich habe vielleicht eine öffentliche Methode für eine öffentliche Klasse, die ich zu einer Paketmethode machen könnte. Das Ändern aller öffentlichen Methoden für jede Klasse in einem Paket wäre ziemlich zeitaufwendig. –

+0

Wenn Sie es mit Methoden machen wollen, dann haben Sie viel größere Probleme. Standardzugriff auf Mitglieder und Konstruktoren ist nützlich als Freund eines armen Mannes, aber IMO ist es am besten, so wenig Freunde wie möglich zu haben (IFYSWIM). –

Verwandte Themen