Vererbung Geerbte Methode verstecken?

[Flashbanger]

Hallo

Ich habe eine Klasse von JTable abgeleitet und möchte bei dieser nun einige Methoden verstecken, da sie in meiner Subklasse nicht vom Benutzer ausgeführt werden sollen und die Komponente unübersichtlich macht.

Ich dachte daran sie einfach mit einer Methode mit gleichen Parametern und gleichem Namen zu überschreiben jedoch mit "private" statt "public".

Doch anscheinend geht das so nicht... ich bekomme einen Compiler-Hinweis

"...cannot overrride ... attempting to assign weaker access privileges; was public"

Kann man in Java keine Methoden und Eigenschaften der Elternklasse verstecken?

Liebe Grüße

Flashbanger

 

[nillehammer]

Nein, das geht leider nicht. Man kann die Sichbarkeit von geerbten Methoden in Java nur erweitern, nicht einschränken. Die einzige Möglichkeit, die Nutzung zu verhindern ist, sie in der abgeleiteten Klasse mit der selben Sichbarkeit zu überschreiben und eine Exception zu werfen, z.B. UnsupportedOperationException. Das sollte man dann im JavaDoc dokumentieren. Außerdem kann man die Methoden per Annotation und im JavaDoc als deprecated kennzeichnen. So sieht der Programmierer in den meisten IDEs, dass er eine Methode benutzt, die er eigentlich nicht benutzen sollte.

 

[Final_Striker]

Du kannst doch die Methode überschreiben und den Rumpf leer lassen. Der Benutzer kann sie dann zwar ausführen aber es wird nichts passieren.

 

[Flashbanger]

Dann steht sie aber immernoch im Komponenten-Editor meiner IDE(Netbeans) und in der automatischen Code-Vervollständigung oder?

Liebe Grüße

Flashbanger

 

[Final_Striker]

Ja. In wie weit stört dich das?

 

[nillehammer]

Dann steht sie aber immernoch im Komponenten-Editor meiner IDE(Netbeans) und in der automatischen Code-Vervollständigung oder?

Ja, lässt sich nicht ändern. Du könntest statt Vererbung aber auch mit Komposition arbeiten. Sprich, Du hast eine lokale Membervariable JTable, auf die Du die von Dir gewünschten Methodenaufrufe delegierst. Dann wärest Du frei bei der Methodenwahl. Du müsstest dann natürlich von einer anderen geeigneten Oberklasse oder Interface ableiten, damit Du Deine Komponente zur Anzeige bringen kannst.

 

[Marco13]

Methoden verstecken (durch überschreiben und vielleicht werfen einer UnsupportedOperationException :autsch: ) ist doch Bogus - eben gerade das Gegenteil des Sinnes von Vererbung. Einerseits ist der Wunsch nachvollziehbar (dass z.B. JComponent von Container erbt ist ja eigentlich ... "unpassend"), aber ... von einer Klasse wie JTable erben allein klingt IMHO schon fragwürdig. Warum erbst du davon? Welche Methoden kommen dazu, welche werden verändert, und welche würdest du weglassen?

 

[nillehammer]

Methoden verstecken (durch überschreiben und vielleicht werfen einer UnsupportedOperationException ) ist doch Bogus - eben gerade das Gegenteil des Sinnes von Vererbung

Stimmt. Ich wollte die Sinnhaftigkeit aber nicht in Frage stellen und habe geschrieben, was man machen kann. So wird es sogar in den Java-APIs selbst gemacht (z.B. siehe die Interfaces des Collection-Frameworks)

 

[Ark]

So wird es sogar in den Java-APIs selbst gemacht (z.B. siehe die Interfaces des Collection-Frameworks)

Dort ist dann aber bereits im Interface spezifiziert, dass eine UOE auftreten darf.

Ark

 

[Flashbanger]

Ich will auf der JTable kleine Icons darstellen. Meine ersten Test waren auch erfolgreich und die Bilder werden bereits angezeigt.

Nun will ich aber der geerbten Klasse eine Methode verpassen die einen Dateipfad verlangt und wahlweise seine Daten aus dieser Datei laden oder in diese Datei speichern soll. Wie das geschehen soll ist hier allerdings offtopic.

Da ich 80% der Methoden von JTable dafür nicht brauche oder nur intern brauche(z.b. muss ich von außen keinen Zugriff auf TableModel haben, da dies überhaupt nicht vom User verändert wird) - Zwar könnte ich die Methoden überschreiben und ins Leere laufen lassen, doch dadurch wird das Problem sehr unelegant gelöst, da die Methoden weiterhin existieren, der User mit Ihnen jedoch keinen Unfug mehr anstellen kann.

Mein eigener Lösungsansatz wäre ein Container, der selbst am besten kaum öffentliche Eigenschaften&Methoden besitzt und die geerbte Klasse auf sich darstellt. Die geerbte Klasse wäre dann im Container "private". Doch was wäre so ein schlanker Container?

Liebe Grüße

Flashbanger

 

[tfa]

Dort ist dann aber bereits im Interface spezifiziert, dass eine UOE auftreten darf.

Ark

Ausserdem, wer sagt, dass alles in der Java-API gut ist?

 

[Marco13]

@tfa: http://www.java-forum.org/softwareentwicklung/76540-sinn-unsupportedoperationexception.html hatte ich auch schonmal einen Thread aufgemacht. Wenn man mal versucht, eine etwas komplexere Hierarchie in diesem Sinne zu gestalten, merkt man schnell, dass das, was in Java Collections API Design FAQ gesagt wird, keine lahme Ausrede ist

@Topic: Icons darstellen ist erstmal larifari, da setzt mal einen passenden CellRenderer von außen. Was du dann von "wahlweise seine Daten aus dieser Datei laden oder in diese Datei speichern" gesagt hast, erschließt sich nicht ganz, und hat auch nichts mit Icons zu tun. Die JTable zeigt Daten an. Wenn du nicht sagen kannst: "Jedes Objekt meiner Klasse IST EINE JTable", dann ist Vererbung dort der falsche Weg. Daten Lesen und schreiben hat im Idealfall nichts mit dem GUI (und damit auch nichts mit einer JTable) zu tun (wobei Icons Grenzfälle sind, ggf. müßtest du das näher erläutern). Wenn du nur die Daten lesen und schreiben willst, die IN der Tabelle stehen, dann sollten es zwei statische Utility-Methoden tun: Die eine liest eine Datei und spuckt ein TableModel aus, die andere bekommt ein TableModel und schreibt es in eine Datei.

 

[Flashbanger]

Ich wollte mit meiner Klasse eine Komponente schreiben, die ein Gleisbild darstellen kann. Dies wird aus kleinen png-Bildern zusammengesetzt. Das klappt auch ganz gut soweit. Meine Klasse soll am Ende eigene Events besitzen, und etwa beim Klick auf eine bestimmtes Icon(Bspw ein rotes Signal) wird das dortige Icon geändert (Gegen ein grünes Signal) und ein Event aufgerufen. In Delphi hab ich das alles schonmal geschrieben, den grundsätzlichen Ablauf bekomme ich da denk ich mal hin.

ich hab mich desshalb für JTable entschieden, da diese sich relativ einfach zu meiner Komponente erweitern lässt. Doch ein direktes Erbe von JTable erzeugt sehr viele "Altlasten". Beispielsweise muss der User nicht die Zellgröße einstellen können. Die Größe der png-Bilder gibt die Zellgröße vor. Es ist mit bereits gelungen die JTable in einer von JPanel geerbten Klasse zu kapseln. Doch auch JPanel ist doch noch relativ schwer.

Liebe Grüße

Flashbanger

 

[dev281]

Doch auch JPanel ist doch noch relativ schwer.

Es wurde hier bereits gesagt: Nutze Komposition statt Vererbung

 

[hdi]

Du kannst sowas durchaus erreichen, und zwar durch Komposition und Delegation statt Vererbung.

D.h.: Du erbst nicht von JTable sondern du hast eine Instanz-Variable die auf einen JTable referenziert.

Die Methoden, die in der Kindklasse "von JTable geerbt" sein sollen, implementierst du nach und delegierst an den Table.

z.B.:

public void setModel(TableModel m){
   internalTable.setModel(m);
}

Die Methoden, die nicht da sein sollen, implementierst du auch nicht.

Damit hast du das "versteckt". Ok - es gibt natürlich schon einen Unterschied: Deine Instanz ist typ-technisch nicht mit JTable kompatibel. Ich weiß nicht inwieweit das in deiner App dann Probleme machen kann. Zur Not kannst du immernoch einen Getter für die interne Table-Referenz implementieren...

edit: Oh Gott sorry, scheinbar wurde das ja schon vorgeschlagen. Der letzte Post war so klein, den hab ich gar nicht wahrgenommen.. Sry für Spam

 

[Flashbanger]

Du kannst sowas durchaus erreichen, und zwar durch Komposition und Delegation statt Vererbung.

D.h.: Du erbst nicht von JTable sondern du hast eine Instanz-Variable die auf einen JTable referenziert.

Die Methoden, die in der Kindklasse "von JTable geerbt" sein sollen, implementierst du nach und delegierst an den Table.

Seh ich das richtig.

Ich schreibe eine x-beliebige Klasse, welcher eine JTable übergeben werden kann. Meine Klasse greift dann auf die JTable zu und verändert deren Parameter nach meinen Wünschen und ruft Ihre Methoden auf?

Liebe Grüße

Flashbanger

 

[hdi]

Ja genau. Die JTable muss auch nicht zwangsläufig übergeben werden, die Klasse kann die ja selbst erzeugen und verwalten:

class MyTable{

   private JTable table; // <- Das nennt sich Komposition

   public MyTable(){
       table = new JTable();
   }

   public void setModel(TableModel m){
       table.setModel(m); // <- Das nennt sich Delegation
   }

   ....

}

So kannst du eben eine JTable-Ableitung mit Verstecken einiger JTable-Methoden faken. Aber es ist eben nur ein Fake, da jetzt deine Klasse nicht tpy-kompatibel mit JTable ist. Aber wie gesagt falls du doch mal die JTable brauchst, pack noch rein:

   public JTable getTable(){
       return table; 
   }

Ist halt nur ein Workaround - ein echtes Verstecken von geerbten Methoden gibt es leider nicht, da du die Access Modifier in der Kindklasse nur auflockern kannst (aus protected wird public) aber nicht einschränken kannst (public zu protected oder private).

 

[Marco13]

Wenn du mit "schwer" meinst, dass es viele Methoden hat: Ja. Aber trotzem ist JPanel die "minimale" konkrete Klasse für Components, die es in Swing gibt. Und wenn du das ganze irgendwo anzeigen willst, wirst du nicht drumrumkommen, irgendwo eine JComponent/JPanel zur Verfügung zu stellen. Die eigentliche Funktionalität ist davon ja unabhängig. Bisher klingt es für mich nach zwei Dingen:
1. Du hast mal in Delphi etwas geschrieben, und willst jetzt "das gleiche" in Java schreiben. Unabhängig davon, dass die Sprachen und die APIs unterschiedlich sind, und unabhängig davon, dass vielleicht schon das, was du in Delphi geschrieben hattest, "nicht gut" war, und durch irgendwelche Würgarounds in Java jetzt noch schlimmer wird
2. Du vermischst Model und View, bzw. die GUI mit dem, was dieses "Gleisbild" eigentlich ausmacht, und versuchst, die JTable als allgemeine "Rasterzeichenfläche" zu verwenden...

Aber vielleicht liege ich mit beidem falsch. Anregungen, um das besser zu strukturieren, hast du ja schon. Für weitergehende Tipps müßtest du mehr Infos posten.

 

[benutzer1234]

Doch anscheinend geht das so nicht... ich bekomme einen Compiler-Hinweis

Die Sichtbarkeit darf nicht reduziert werden, weil überall dort, wo ein der Typ einer base class verlangt ist, auch irgendeine sub class dieser Klasse eingesetzt werden können muss.

Base class und sub class hab ich jetzt auf aus dem Wiki-Artikel übernommen: Inheritance (object-oriented programming) - Wikipedia, the free encyclopedia

Die Verfügbarkeit bestimmter Methoden einzuschränken ist sinnvoll u.a. bei der Fehlervorbeugung, wenn es sonst zu viele Möglichkeiten gibt, un um Ausfallwahrscheinlichkeiten/Fehlfunktionen/Überschwemmungen zu minimieren.

Hm, hoffentlich nicht zu diffus.

 

[Andi_CH]

Das geht nur, wenn du nicht vererbst, sondern eine Interfaceklasse davor baust - oder soll ich sagen einen Proxy?
Einfach eine Klasse die genau die Methoden anbietet, die du weitergeben willst und dahinter die der "echten" Klasse aufruft.

 

[bERt0r]

Wenn du einfach nur Bilder in einem Raster anzeigen willst, bist du mit einem JPanel mit GridLayout besser bedient.

 

[Marco13]

Wie groß ist das Raster? Bei mehr als 10x10 ist alles, was auf einzelnen JComponents aufbaut (auch indirekt, wie die JTable) ziemlich fragwürdig. Siehe auch http://www.java-forum.org/java-basi...694-pingpong-selber-schreiben.html#post394005

 

[Flashbanger]

Wie groß ist das Raster? Bei mehr als 10x10 ist alles, was auf einzelnen JComponents aufbaut (auch indirekt, wie die JTable) ziemlich fragwürdig. Siehe auch http://www.java-forum.org/java-basi...694-pingpong-selber-schreiben.html#post394005

nunja das Raster kann schon mal 100x100 oder 200x200 werden.

Ich habe aber eben mal ein kleines Testprogramm geschrieben. Bei diesem wurden alle Zellen der Table mit zufälligen Gleismosaiken gefüllt. Die RAM-Auslastung des Programms stieg von 20 MB auf 60 MB. Würde sich der Speicherverbrauch drastisch reduzieren, wenn ich die Gleismosaike selbst zeichne (z.b. auf ein JScrollPane)? Ich würde dann natürlich nur die Gleismosaike Zeichnen lassen, die gerade im sichtbaren Bereich liegen.

LG Flashbanger

 

[Marco13]

Vermutlich hast du das mit dem Taskmanager nachgeschaut, da haben die 20 oder 60 MB nicht viel zu sagen: Nur weil da 60MB für "Java" steht, heißt das nicht, dass so viel wirklich belegt ist. Es ist schon so, dass bei einem Raster aus Components recht viel Speicher verschwendet wird (siehe die Auflistung im verlinkten Beitrag) allerdings ist das nur ein Teilaspekt. Dort steckt auch ein Haufen "Verwaltungszeug" dahinter. Es sind schlicht und einfach SEHR viele Components. Bei einer JTable wäre das weit, weit weniger Problematisch, aber... auch das wäre ein Bogus-Hack: Eine JTable ist eine Tabelle, mit spalten und Zeilen und Headern und wasweißich. Wenn du ein Raster zeichnen willst, dann solltest du das auch tun. Man braucht dann i.a. nicht mal besonders viel zu tun, um "nur die sichtbaren" Zellen zu zeichnen: Da kümmert sich Swing schon um ziemlich viel.