Problem mit Sichtbarkeit von Methoden über mehrere Pakete

  • Themenstarter Themenstarter ByeBye 201030
  • Beginndatum Beginndatum
B

ByeBye 201030

hi,

ich hab momentan ein Problem mit der Sichtbarkeit von statischen Methoden einer Klasse in fremden Paketen welches ich nicht nachvollziehen kann.
Folgendes:
Ich habe zwei Klassen, A enthält zum Teil öffentliche statische Methoden. Klasse B greift auf diese Methoden zu (großer Teil sind simple setter... ich weiß... öffentlich statisch ist da ziemlich unangebracht.. dazu gleich mehr ;) ). Klasse A & B erben von Thread ("public class A extends Thread...."). Zu Beginn liegen beide Klassen sowie alle anderen Klassen im selben Paket, also es gibt keine Pakete in diesem Projekt. Soweit kein Problem...
Da der Quellcode und das Design recht grottig waren (u.a. viele öffentlich statische setter methoden) habe ich mich erstmal entschlossen eine komplette Refactorisierung durchzuführen. Nachdem ich fertig war hab ich die Klassen in Pakete aufgeteilt. Die Klassen A & B liegen jetzt in 2 unterschiedlichen Paketen und alles funktioniert (es gibt immer noch 2 öffentliche statische Methoden in Klasse A auf die Klasse B zugreift).
Wenn ich jetzt aber in einem Projekt mit dem ursprünglichen Quellcode und Klassen diese genauso in Pakete aufteilen möchte, werden in Klasse B jede Menge Fehler angezeigt. Der Fehler ist, dass angeblich die öffentlichen statischen Methoden aus Klasse A nicht sichtbar sind, die Klasse A selber aber wird erkannt. Es werden auch die richtigen Pakete importiert.

Also... ich habe die beiden Klassen A & B im selben Paket liegen und die öffentlich statischen Methoden aus A werden in B problemlos erkannt. In dem einen Projekt werden diese Methoden nach einer umfrassenden Refaktorisierung und nach der Aufteilung in unterschiedliche Pakete immernoch erkannt. In dem anderen Projekt ohne Refaktorisierung werden dieselben öffentlichen statischen Methoden nicht erkannt, aber die Klasse A selber schon. Als Fehler wird angegeben das die Methoden an dieser Stelle nicht sichtbar sind, trotz "public static".

Ich hoffe es kann mir jemand einen Tipp geben, woran das liegen könnte bzw. was ich eventuell bei der Refaktiorisierung verbessert haben könnte so das das aufteilen in Pakete problemlos funktioniert.
 
Hallo Psychohamster,

hast du das Projekt mal komplett neu kompiliert? Du hast nicht erwähnt, ob bzw. welche IDE du verwendest, aber vielleicht hat diese beim Verschieben der Klassen in ihre Packages keinen Rebuild durchgeführt.

Grüße, Matthias
 
achso.. hab ich total vergessen... wollt die IDE noch hinschreiben ;)
also ich benutze Eclipse 3.4... ich lasse die Projekte generell automatisch bauen, was ja dann bei jeder Veränderung bzw beim Speichern erfolgt.
Ich hab auch manuell den Rebuild gestartet und auch Clean probiert. Hat alles nicht geholfen.
 
ja definitiv "public static" .. das einzige was noch benutzt wird ist "synchronized", in beiden Fällen weswegen ich denke das es nicht an dem Wort liegen sollte. ;)

Edit:

muss mich korrigieren... in dem ursprünglichen Quellcode fehlen "idealerweise" zum Großteil Schlüsselwörter wie "public", "private" ect.
Ich bin davon ausgegangen das die Standardsichtbarkeit "public" wäre. Naja jetzt hab ich überall nen "public" davor gesetzt und es läuft.
Danke für eure Hilfe, das Problem ist jetzt gelöst :)
 
Zuletzt bearbeitet von einem Moderator:
Wenn ich public static setter und threads in einem Satz lese, wird mir ehrlich geasgt Angst und Bange ;). Aus dem Prosatext rauszulesen, was du da genau hast ist kaum möglich. Kannst du etl n Screenshot von den Outlines der Klassen im Eclipse machen?

Gruß
Ollie
 
was meinst du mit Outlines?

Ja als ich die Sache mit den "public static" settern und Threads gesehen hab ich auch so meine Probleme gekriegt (abgesehen von dem restlichen recht grusligen Quellcode). Deswegen auch ein umfassendes Refactoring um dieses Problem möglichst komplett zu eliminieren. Trotzdem sind noch 2 dieser Methoden übrig geblieben. Da ich eine GUI-Klasse habe in der ich zur Laufzeit ActionListener erstelle und diese static Methoden verlangen soweit ich das festgestellt habe. In diesem Methoden muss ich dann an die andere Klasse Werte übergeben, deshalb noch die beiden verbleibenden public static setter.
Ich persönlich finde für die Größe des Projekts Threads überflüssig. Ich werde aber wohl nicht drumherum kommen, weil ich auf der Oberfläche weiterhin die Buttons anklicken können muss (und somit neue Informationen an die darunterliegende Klasse übergebe) während die darunterliegende Klasse schon etwas macht. Also in Echtzeit/sofort auf neue Eingaben reagiert wird ohne die bereits gestarteten Vorgänge rückgängig zu machen bzw abbrechen zu müssen.
Ich bin kein Java-Jünger (bin eher mit .Net und C# vertraut (dort wüsste ich auch auf alle Fälle wie ich einfach die Threads eliminieren könnte ohne das es zu Problemen kommt)) und habe auch kaum praktische Erfahrung mit Threads deswegen liest sich das vielleicht gruslig was ich hier schreibe ;)
 
Zuletzt bearbeitet von einem Moderator:
diese grafische ansicht, welche klasse welche methoden hat... im package explorer z.B. wenn du die klasse aufklappst...
 
ok.. ich denke ich habe das richtige
 

Anhänge

  • outlines.jpg
    outlines.jpg
    97 KB · Aufrufe: 29
Wow, wie wenig ahnung muss man haben um sowas zu designen? Da bleibt eigentlich nur der Rat: wegwerfen und richtig machen. Aber auf deine Frage bezogen die meisten Methoden sind im default (blaues Dreieck) also nur im entsprechenden Package sichtbar.

Gruß
Ollie
 

Neue Beiträge

Zurück