Java: Best Practice für die Lokalisierung Objekt über viele GUI-Objekte zu teilen?

Question

Was wäre die beste Praxis Lokalisierungsobjekt für die gemeinsame Nutzung (in diesem Fall Resource, wo ich speichert alle Übersetzungen zu tun) über viele GUI-Objekte in app? Ich habe einige Ideen, aber beide haben Nachteile:

1) Resource über jede GUI-Klasse Konstruktor übergeben, aber dann muß ich es in jeder Klasse speichern (für spätere Verwendung) - Mittel, um den gleichen Code in jeder Klasse mit immer und immer wieder

2) erklären Resource als public static (aber nicht endgültig, weil ich brauche kann es ändern - zB Sprache geändert) in Haupt-GUI-Klasse (zB „public static Resource msg“), dann greifen sie später über sie immer (zB Aufruf MainGuiClass.msg.getString ( „etwas“)), aber dann kann es auch von jeder anderen GUI-Klasse im selben Paket ...

modifiziert / zerstört werden

Vielleicht gibt es einige bessere Praxis die gemeinsame Nutzung zu tun?

Danke.

Answer 1

Das globale Resource Objekt kann nicht endgültig sein, sondern sollte in einer Karte zwischengespeichert werden. Ändern der Sprache benötigen diesen Artikel nicht ändern:

import java.util.HashMap;
import java.util.Locale;
import java.util.Map;
import java.util.ResourceBundle;

public class UIBundle {
    private static final Map<Locale, ResourceBundle> allUIResources = new HashMap<Locale, ResourceBundle>();

    public static String getString(final String key) {
        return getString(key, Locale.getDefault());
    }

    public static String getString(final String key, final Locale locale) {
        ResourceBundle rb = allUIResources.get(locale);
        if (rb == null) {
            rb = ResourceBundle.getBundle("my-ui-resource", locale);
            allUIResources.put(locale, rb);
        }
        return rb.getString(key);
    }

}

Mit diesem Code können Sie entweder Zugriff Texte in bestimmten Sprachen / locales oder benutzen Sie einfach das Standard-Gebietsschema. Wenn Sie Ihren Standort wechseln möchten, nur das Standard-Gebietsschema festgelegt. Ihre UI muss über locale Veränderungen erfahren, so dass Sie für alle Ihre UI-Komponenten eine Listener-Schnittstelle einführen müssen möglicherweise ( Property , Property ) und nicht das Gebietsschema direkt ändern.

Answer 2

Sie könnten eine Caching-Fabrik implementieren, die die Resource liefert basierend auf dem Wert eines Eingabegebietsschema-Parameter. Beim ersten Aufruf wird die Resource aufgebaut und dann in einem statischen Referenzzwischengespeichert, die anschließend zurückzugeführt und in späteren Anrufen in die Fabrik wiederverwendet werden können.

Answer 3

Wenn Sie sind besorgt über andere Klassen Dinge, die Sie nicht auf ein Objekt wollen, machen es zu einem geschützten / privaten Bereich einer Klasse, die die Methoden hat Sie wollen es durchgeführt werden.

Globals sind böse, aber manchmal ihre Bequemlichkeit ist größer als ihre Bösartigkeit.

Answer 4

Die Klasse Resource Geräte bereits einen Cache, so gibt es keine Notwendigkeit, das Caching selbst zu implementieren. Ihr Zugang Klasse kann als Singleton implementiert werden. Zum Umschalten der Sprache, die ich eine Thread für das Gebietsschema verwenden:

public final class ThreadLocale extends ThreadLocal<Locale>
{
    public static final ThreadLocale theInstance = new ThreadLocale ();

    private ThreadLocale () 
    {
        super ();
    }

    protected Locale initialValue()
    {
        return Locale.getDefault ();
    }
}

Bei dem Verfahren der Zugriffsklasse, die den Text aus der Ressource bekommt Bündel ich das aktuellen Thread Gebietsschema verwenden:

public synchronized String getMessage (Object messageKey, Locale locale) throws MissingResourceException
{
    ResourceBundle resourceBundle = null;
    resourceBundle = ResourceBundle.getBundle (filename, ThreadLocale.theInstance.get ());
    return resourceBundle.getString (messageKey.toString ());
}

So haben Sie eine locale für die einzelnen Threads und nicht global.