Klasse Toolkit?

[Guest]

Hallo,

in der Java-Insel steht:

"Die abstrakte Klasse Toolkit abstrahiert von system- und bildschirmabhängigen Implementierungen."

Das verstehe ich nicht ganz. Was sind Beispiele für System- und Bildschirmabhängige Implementierungen? Und wozu muss man sich mittels getDefaultToolkit das entsprechenden Toolkit des Betriebssystems zurückgeben lassen?

Warum wurde es nicht so gelöst, dass man einfach eine normale Klasse Toolkit erzeugen müsste, die intern dann auf Betriebssystem spezifische Dinge "umleitet",

also statt Toolkit.getDefaultToolkit ein

Toolkit.getScreenDimension oder so und das liefert dann unter Windows/Linux usw. dann auch die entsprechenden Werte... Warum also der Umweg über die get Methode. Was ist der Vorteil das über eine getMethode zu lösen?

Fragen über Fragen

 

[SlaterB]

die unterschiedlichen Implementierungen erfordern auf jeden Fall spezielle Klassen,
also ist ein Interface bzw. eine abstrakte Oberklasse mit Auflistung aller Methoden auf jeden Fall notwendig,

auf jeden Fall wird auch ein Objekt dieser speziellen Klasse benötigt,

nun kann man entweder genau 5 Zeilen Code schreiben, die dieses Objekt zurückgeben und alles ist fertig und einsatzbereit,
oder man definiert für 30 Methoden jeweils 5 Zeilen Code einer statischen Methode, die an das Toolkit-Objekt delegiert,
wozu?
damit du den getDefaultToolkit()-Aufruf sparst?

da Objekte eh viel objektorientierter sind, macht das keinen rechten Sinn,
außerdem verschenkt man dadurch die Möglichkeiten der Vererbung, einer eigenen Unterklasse von Toolkit

wenn du möchstest, kannst du dir aber selber eine Klasse mit statischen Methoden schreiben, die unsichtbar an das DefaultToolkit weiterleiten

 

[Gast]

Hallo Christian,

ok, danke für die Antwort.

Wie meinst du aber das:

>nun kann man entweder genau 5 Zeilen Code schreiben, die >dieses Objekt zurückgeben und alles ist fertig und einsatzbereit,
>oder man definiert für 30 Methoden jeweils 5 Zeilen Code

 

[SlaterB]

das Toolkit-Objekt kann man bereist nach isDynamicLayoutActive() fragen oder was immer man es fragen möchte,

damit das auch statisch geht, müsste man eine Methode

public static boolean isDynamicLayoutActive() {
// test ob DefaultToolkit schon vorhanden, evtl. erst initialisieren
return Klasse.staticToolkit.isDynamicLayoutActive();
}

schreiben, dieser Aufwand für jede Methode einzeln


edit: kürzer wäre sicherlich

public static boolean isDynamicLayoutActive() {
return getDefaultToolKit().isDynamicLayoutActive();
}

dennoch zusätzlicher unschöner Aufwand

 

[Gast]

Hallo,

das habe ich jetzt irgendwie nicht verstanden :-( Es ging doch um das zurückgeben des Objektes. Das dadurch weniger Schreibaufwand nötig ist. Kannst du es bitte nochmal erklären.

Danke schön

 

[SlaterB]

durch das Zurückgeben des Objektes spart man sich die statischen Methoden, mann muss sie einfach nicht schreiben, kann sie gedanklich wegradieren,
das ist 'weniger Schreibaufwand'

 

[Gast]

Hallo,

ich hab immernoch nicht verstanden wieso da statische methoden sonst nötig sind...

 

[SlaterB]

nötig sind sie nicht, das stand nur in deinem ersten Posting,
frei neu zusammengesetzt:
'warum nicht eine statische Methode Toolkit.getScreenDimension() statt Toolkit.getDefaultToolkit().getScreenDimension()?'

 

[slawaweis]

"Die abstrakte Klasse Toolkit abstrahiert von system- und bildschirmabhängigen Implementierungen."

in dem Buch wurde es unglücklich ausgedruckt, was vor allem Anfänger verwirrt. Toolkit ist im Grunde eine abstrakte Schnittstelle zu bestimmten betriebssystemabhängigen Eigenschaften oder Funktionen. Weiterhin ist diese Schnittstelle universell, d.h. man muss nicht wissen, auf welchen OS gerade das Programm läuft. Die drunterliegende Implementierung der JVM mappt dann die Aufrufe oder Anforderungen des Toolkits auf die OS Implementierung.

Das verstehe ich nicht ganz. Was sind Beispiele für System- und Bildschirmabhängige Implementierungen? Und wozu muss man sich mittels getDefaultToolkit das entsprechenden Toolkit des Betriebssystems zurückgeben lassen?

für die erste Frage muss man sich einwenig mit Betriebssystemen beschäftigen. Wenn man überwiegend nur Windows kennt, kennt man quasi nur einen Desktop. Doch auf anderen System gibt es mehrere Desktop Implementierungen (z.B. Gnome, KDE) oder GUI-Systeme, die komplett ohne Fenster auskommen (z.B. an Supermarktkassen oft zu beobachten). Für jede dieser Varianten eines Desktops gibt es eigene Toolkit Klassen in der Implementierung der JVM. Man kann es sich so vorstellen (der folgende Code ist rein fiktiv):

 private static Toolkit default_toolkit = null;

 // …

 public static Toolkit getDefaultToolkit()
  {
  if(default_toolkit == null)
    {
    if(os_desktop.equals("gnome"))
      default_toolkit = new GnomeToolkit();
    else if(os_desktop.equals("kde"))
      default_toolkit = new KDEToolkit();
    }
  return default_toolkit;
  }

Deine zweite Frage kann man folgend beantworten: war eine Designentscheidung. Man hätte es so oder so lösen können, also entweder mit getDefaultToolkit() oder direkt über statische Funktionen. Doch vor allem bei der zweiten Variante würde man immer noch eine weitere Klasse brauchen, die eben die ganzen Funktionen wieder als abstrakt definiert, damit davon die verschiedenen Implementierungen abgeleitet werden können. D.h. am Ende gäbe es 2 ähnliche Klassen, eine mit abstrakten und eine mit statischen Funktionen.

Ein Problem mit Toolkit.getDefaultToolkit() sehe ich übrigens nicht. Bei der Komplexität der heutigen Programme ist so was egal. Außerdem kann man so vorgehen, wenn man Toolkit länger verwenden möchte:

 Toolkit toolkit = Toolkit.getDefaultToolkit();

 toolkit.get...
 toolkit.get...
 toolkit.get...
 toolkit.get...

Ein weiterer Vorteil von Toolkit.getDefaultToolkit() ergibt sich, wenn man eigene Desktops implementieren will. Theoretisch kann man in Java einen kompletten Desktop schreiben, der den nativen überlagert. Dafür könnte man dann eine eigene Toolkit Klasse ableiten.

Slawa

 

[SlaterB]

sag ich doch

 

[Gast]

Hallo,

danke für eure Antworten... OK, getDefaultToolkit liefert dann eine entsprechende Implementierung zurück. Soweit verstanden. Ich meinte aber wieso man nicht einfach

Toolkit t = new Toolkit() schreiben könnte und die Klasse ermittelt dann selbst wie die entsprechende Implementierung aussieht ala

public Toolkit()
{
if(Betriebssystem==Windows) Instanz ist Windows Toolkit
if(Betriebssystem==Linux) Instanz ist Linux Toolkit
}

die Methode getDefaultToolkit macht doch im Grunde nix anderes...

 

[Schandro]

Das ist ne Factory-Methode. Dadurch wird nicht jedes mal ne neue Instanz von Toolkit erstellt. Ich denke mal, beim erstenAufruf von getDefaultToolkit() wird ne neue Instanz erstellt und zurückgegeben, alle darauf folgenden Aufrufe geben einfach nurnoch ne Referenz auf die bereits erstellte Instanz zurück. Sowas würde nicht gehen, wenn der Benutzer jedesmal den Konstruktor von Toolkit benutzen würde.

EDIT: Ok, hab grad im Quellcode nachgeguckt. Toolkit ist wirklich en Singleton, d.h. er hat ne statische Variable vom eigenen Typ "Toolkit" und solang diese Variable nicht null ist, wird bei getDefaultToolkit() einfach nur diese returnt und nicht ein neues Object erstellt

 

[HoaX]

Weil das in Java nicht geht. new BeliebigeKlasse() liefert _immer_ eine Instanz von BeliebigeKlasse, und nie plötzlich eine andere Implementierung.

 

[slawaweis]

danke für eure Antworten... OK, getDefaultToolkit liefert dann eine entsprechende Implementierung zurück. Soweit verstanden. Ich meinte aber wieso man nicht einfach

Toolkit t = new Toolkit() schreiben könnte und die Klasse ermittelt dann selbst wie die entsprechende Implementierung aussieht ala

public Toolkit()
{
if(Betriebssystem==Windows) Instanz ist Windows Toolkit
if(Betriebssystem==Linux) Instanz ist Linux Toolkit
}

die Methode getDefaultToolkit macht doch im Grunde nix anderes...

dein Model entspricht einem Delegator-Pattern, d.h. eine Klasse macht nicht anderes, als die Funktionsaufrufe an eine andere Klasse weiterzuleiten. Doch in dem Toolkit spielt das Singleton-Pattern eine Rolle, den eine Instanz von Toolkit darf es nur einmal im System geben, und genau das wird mit getDefaultToolkit dem Programmierer klargemacht. Das hat wieder mal was mit dem Betriebssystem zu tun. Wer schon mal Win32, SWT oder allgemein C/C++ programmiert hat, der weis, dass wenn man die benötigten Ressourcen anfordert, man diese irgendwann selber freigeben muss. Toolkit greift auf diese Betriebssystemressourcen zu und hält diese bis zum Ende der JVM. Am Ende, wenn die JVM beendet wird, werden die Ressourcen in der finalize() Methode (hat jedes Object) wieder freigegeben. Würden diese Ressourcen nicht freigegeben, würden die auch nach dem Beenden der JVM noch belegt sein. Das Singleton-Pattern ist jetzt notwendig damit verschiedenen Instanzen von Toolkit nicht die selben Ressourcen mehrfach anfordern. Wenn man z.B. eine Grafik mit getImage(URL url) als Systemressource anfordern, dann wird diese nur einmal als Systemressource angelegt und bei erneuten Aufruf immer wieder zurückgegeben. Ist auch eine Optimierungssache.

Doch im Grunde ist es egal wie es umgesetzt wurde, war eben eine Designentscheidung des AWT-Teams. Ich schreibe öfters größere Swing-Anwendungen, benutze Toolkit aber nur 4-5 Mal pro Projekt. Wer unbedingt Toolkit beliebig instanzieren will, kann ohne Probleme sich einen Delegator schreiben:

public class MyToolkit extends Toolkit
{
 protected Toolkit toolkit = null;

 public MyToolkit()
  {
  this.toolkit = Toolkit.getDefaultToolkit();
  }

// Implementation aller Toolkit Funktionen als Delegatoren
}

// Benutzung
Toolkit t1 = new MyToolkit();
Toolkit t2 = new MyToolkit();
Toolkit t3 = new MyToolkit();

doch es ändert nichts an der Funktionalität. Das AWT-Team hätte es damals (1996) auch so umsetzen können, allerdings wüsten dann die Programmierer nicht auf Anhieb, ob es ein Singleton-Pattern ist oder ob jedes Toolkit die selben Ressourcen mehrfach belegt. Ist auch eine Art Selbstdokumentation: "Programmierer/in sehe da, ein Singleton!"

Slawa

 

[Ebenius]

[...] Doch in dem Toolkit spielt das Singleton-Pattern eine Rolle, den eine Instanz von Toolkit darf es nur einmal im System geben, und genau das wird mit getDefaultToolkit dem Programmierer klargemacht.

Ein Singleton ist es nicht. Singleton garantiert maximal eine Instanz. Zitat aus der API-Doc von Component.getToolkit():

Gets the toolkit of this component. Note that the frame that contains a component controls which toolkit is used by that component. Therefore if the component is moved from one frame to another, the toolkit it uses may change.

Ebenius