Stil ? - ....Nein nicht das Ende des Besens ^^

[kaoZ]

Aloha , ich bin in letzer Zeit immer wieder über die tatsache gestolpert das in der Standard API immer folgende Konstrukte notwendig sind um z.B bei einem JDialog Komponenten einen Rahmen zu setzen

dialog.getContentPane().setBorder(xxx);

hier wird erst über einen getter das Root-Element geholt und dann (indirekt) darüber auf dessen Setter zugegriffen .

Ich meine Irgendwo mal gelesen zu haben das dies aber schlechter Stil ist, und man das ganze lieber über delegation lösen sollte, sprich in der Komponenten oder dem Root Element die Methode so überschreiben / und oder anbieten, das diese dann an die gewünschte Komponenten Delegiert ?

Ich habe es bislang immer so realisiert das ich genau dies umgesetzt habe, sprich wenn ich eine eigene Klasse hatte z.B (eine die ein UI darstellt) habe ich dort direkt Methoden angeboten die an die jeweilige Componente Delegieren, ( dies steigert natürlich die Anzahl an Methoden, führt allerdings zu kürzeren Aufrufhierarchien und vermeidet Verkettung von Punkt-Operatoren)

hier ist z.B contentPane ein JPanel und die Gui hält (als Root-Element) eine Referenz auf ihr Child

public void addContent(JComponent comp){
  contentPane.add(comp);
}

Was oder wie ist es denn nun am Sinnvollsten ? Stilistisch am schönsten ?
Was ist Konzeptionell richtig ?

Mit erstere, Lösungsansatz spart man sich natürlich die Methoden in den Superklassen / und oder RootElementen.


Haut mal raus was ihr davon haltet

 

[Joose]

Ich meine Irgendwo mal gelesen zu haben das dies aber schlechter Stil ist, und man das ganze lieber über delegation lösen sollte, sprich in der Komponenten oder dem Root Element die Methode so überschreiben / und oder anbieten, das diese dann an die gewünschte Komponenten Delegiert ?

Fehlersuche:

Der Nachteil bei solchen Anweisungsverkettungen ist die Fehlersuche.
Bei kurzen ist es nicht so gravierend, aber viele lassen sich dazu hinreißen dort viele Methoden aufzurufen und haben plötzlich 5 oder mehr getter hintereinander stehen. Wenn nun in dieser Zeile zum Beispiel eine NullpointerException fliegt, woher weißt du nun wo der Fehler liegt? Beim 1.Getter, beim 2.? Man muss die Zeile wieder aufsplitten bzw. per Debugger kontrollieren.

Beim Weiterdelegieren kann man ohne Probleme im StackTrace sehen wo der Fehler liegt und den Aufrufer interessiert es nicht was man selber macht bzw. weiteraufruft.

Referenzen:

Desweiteren kann es sein das viele Abhängigkeiten nur wegen solchen Verkettungen entstehen. Weil du weißt nur welche Methoden man weiterverwenden kann wenn die entsprechende JAR referenziert wird.

Verkettung
A referenziert B
A referenziert C
B referenziert C

Delegierung
A referenziert B
B referenziert C

Ändert man C kann es sein das man A und B ändern muss, anders nur B.

Du kannst auch eine Parallel zu unserer Arbeitswelt ziehen: Ein Chef wird nicht den untersten Arbeiter direkt eine Aufgabe zuteilen (Ausnahmen gibts wahrscheinlich, aber eben Ausnahmen). Es wird auch die Hierarchie eingehalten: Chef->Abteilungsleiter->Arbeiter

 

[kaoZ]

Also ist doch der Weg den ich bisher gewählt habe besser ?

Ich bin eigentlich ein Freund davon dinge möglichst Atomar zu gestalten.

(auch wenn dies Bedeutet das meistens die Anzahl der Klassen und oder Methoden auch in dieser Relation wachsen)

Ich kann so wie ich es bisher immer gehalten hab zumindest eben genau das nachvollziehen , wenn ich einen Fehler suche laufe ich einfach die Aufrufhierarchie ab und sehe dann genau wo an welcher stelle der Fehler auftritt.

Beim Weiterdelegieren kann man ohne Probleme im StackTrace sehen wo der Fehler liegt und den Aufrufer interessiert es nicht was man selber macht bzw. weiteraufruft.

Aber warum isses dann in der API so das es eben nicht eingehalten wird ?

 

[ssoul26]

Sei doch froh, dass die API dir alle Freiheiten gibt. Willst du delegieren, so tue es, es bleibt dir überlassen. Die einen wollen es so, die anderen wiederum nicht. Das ist der Sinn der freien API.

 

[kaoZ]

Sei doch froh, dass die API dir alle Freiheiten gibt. Willst du delegieren, so tue es, es bleibt dir überlassen. Die einen wollen es so, die anderen wiederum nicht. Das ist der Sinn der freien API.

Eben genau diese Möglichkeit habe ich aber in besagtem Fall nicht (ausser ich erstelle eine Subklasse), ich bin dazu 'gezwungen' eben indirekt attribute über verkettung von Gettern und Settern zu ändern, da eben eine Methode welche einfach an das Rootpane delegiert hier fehlt

sprich es gibt z.B im JDialog keine Methode setBorder(Border b);
sonder du MUSST du eben den besagten weg über den getter nehmen

getContentPane().setBorder(xxx);

gut das ist nun nicht gravierend da die Aufrufhierarchie gering ist, aber es geht ja auch um das Prinzip,
und darum das ich eben mal gelesen habe das eben genau das schlechter Stil ist.

ich müsste hier eine Klasse ableiten um eben gewünschte Funktionalität hinzuzufügen.

 

[X5-599]

Mal das Prinzip außen vor gelassen; Ich verstehe dein Beispiel nicht. JDialog hat nichts mit Bordern am Hut. Border tauchen in der Klasse JComponent auf. Zu setzen per public Methode. Also kann man bei jeder davon ableitenden Klasse eben diese Methode zum setzen eines Borders nutzen.

 

[kaoZ]

JDialog hat nichts mit Bordern am Hut.

das ist natürlich korrekt, und dem will ich auch nicht wiedersprechen, dennoch ist ein JDialog ja bereits von einem Top level container umgeben, welcher eben diese Funktionalität bietet, warum bietet man dann im JDialog dann nicht eben eine Methode an welche eben diese Funktion direkt bereitstellt ?

Und du hast natürlich recht, in der Klasse Component / Container welche eine Superklasse von JComponent ist steht die Funktionalität nicht zur verfügung,
erst mit JComponent gibt es die möglichkeit der Komponente einen Border zusetzen.

JDialog erbt aber in seiner Hierarchie von Dialog und somit Generalisiert von Component und nicht von JComponent, das habe ich übersehen.

Dennoch wäre ist nun doch rein vom Faktor des logischen standpunktes aus nicht sinnvoll einen JDialog welcher ja eine Referenz auf den ihn umgebenen Top - Level Container halten muss ( also diesen als sein Attribut verwaltet hier ein JRootPane), auch eine Methode zu verpassen welche es ermöglicht direkt dessen attribute über Delegation zu beeinflussen ?

 

[X5-599]

Ok, Ich verstehe. Aber um JDialog mit einer setBorder Methode auszustatten müsste sichergestellt sein, dass der Container (ContentPane) immer eine Spezialisierung von JComponent ist. Hier hat man sich aber auf Container als Klasse geeinigt. Warum weiß ich nicht, wird wohl aber auch seinen Grund gehabt haben.

Ansonsten verstehe ich von solcher Architektur nicht genug, um jetzt zu sagen wo die Vorteile/Nachteile von solchen Delegates liegen.

 

[dzim]

Ich glaub, das "Problem" ist einfach, dass Swing eine Lightweight-UI ist und vom Host-System eigentlich nur das leere Fenster zu verfügung gestellt bekommt. Der Rest wird dann quasi live auf dem Canvas, oder was dahinter steht, gezeichnet.
Also ja: Das ist die vielgelobte Freiheit, die man da hat.

Da ich mit Swing nichts am Hut hab, möchte ich nur eine Frage stellen: Heisst dass, es gibt keine Systemumrandung? Keine Fensterbuttons etc.? Oder gibt es die doch, aber du hast dich nur gerade entschieden, ein undekoriertes Fenster zu nehmen? Nur so aus reiner Neugierde...

 

[kaoZ]

Da ich mit Swing nichts am Hut hab, möchte ich nur eine Frage stellen: Heisst dass, es gibt keine Systemumrandung? Keine Fensterbuttons etc.? Oder gibt es die doch, aber du hast dich nur gerade entschieden, ein undekoriertes Fenster zu nehmen? Nur so aus reiner Neugierde...

Nene, da gibt es Standardmäßig Rahmen, in diesem Speziellen Fall ging es darum den Rahmen des Dialoges anzupassen, in diesem Fall den der JRootPane welche als contentPane ( Top-Level-Container ) für den JDialog verwendet wird , in meinem Fall wollte ich einen EmptyBorder setzen, dies ging eben nur diese Aufrufhierarchie, da JDialog keine methode anbietet die an die RootPane delegiert, was mich eben wunderte da ich wie gesagt schonmal gelesen hatte das eben genau das verwenden dieser Art aufrufhierarchie vermieden werden sollte, und man lieber mit delegate arbeiten sollte ( so wie ich es im normalfall eigentlich auch immer mache ).

Ok, Ich verstehe. Aber um JDialog mit einer setBorder Methode auszustatten müsste sichergestellt sein, dass der Container (ContentPane) immer eine Spezialisierung von JComponent ist. Hier hat man sich aber auf Container als Klasse geeinigt. Warum weiß ich nicht, wird wohl aber auch seinen Grund gehabt haben.

Das kann natürlich sein das es in diesem Fall absichtlich so gemacht worden ist um hier die 'freiheit' zu lassen und sich deshalb darauf geeinigt hat Container als Grundlage zu verwenden .

 

[Harry Kane]

Ich würde solche Delegates nur verwenden, wenn mich der alternative Weg mit den verketten Calls zwingen würde, einen Teil der API offenzulegen, den ich lieber verstecken würde. Aber wenn es darum geht, eine sowieso öffentlich zugängliche Eigenschaft eines sowieso öffentlich zugänglichen member zu verändern, sehe ich keinen Grund für ein delegate. Bei verketteten Aufrufen, die immer wieder zu Problemen führen, die aber auch nicht in ihre Einzelteile zerlegen möchte, weil sie so komplex sind, und die man gleichzeitig häufig braucht, würde ich mir in einer Utility Klasse eine statische Hilfsmethode anlegen.
Die delegates können nämlich eine API massiv aufblähen. Was ist, wenn du nicht die Border der content pane sondern deren Layout setzen möchtest? Oder den foreground der glass pane? Für welche Eigenschaft von welchem member soll man delegates anbieten, für welche nicht?

 

[kaoZ]

Die delegates können nämlich eine API massiv aufblähen. Was ist, wenn du nicht die Border der content pane sondern deren Layout setzen möchtest? Oder den foreground der glass pane? Für welche Eigenschaft von welchem member soll man delegates anbieten, für welche nicht?

Das ist denke ich der Hauptgrund dafür das man sich nicht für Delegates sonder für die Verkettung entschieden hat, ist ja auch logisch , in gewisser hinsicht.