Designproblem

[Gast]

Hallo,

ich habe eine Applikationsklasse A, die die Applikation repräsentiert, initialisiert und ein RMI-Objekt (rmiServices) erzeugt. Die Klasse DB regelt den Datenbankzugriff und verwendet dazu das rmiServices - Objekt. D.h. die Applikationsklasse erzeugt ein DB-Objekt (databaseAccess) indem es im DB-Konstruktor das rmiServices-Objekt übergibt.
Da das databaseAccess-Objekt nun aber von vielen anderen Objekten in der Applikation verwendet wird, stellt sich mir nun die Frage, wie ich das Objekt den anderen Klassen zugänglich mache. Im wesentlichen fallen mir zwei Möglichkeiten ein, die ich aber beide nicht für ideal halte:

(1) Ich reiche das databaseAccess-Objekt an alle Klassen durch, die es benötigen. Das halte ich aber für etwas
umständlich (vor allem auch deshalb, weil ich es über Klassen, die gar keinen Datenbankzugriff brauchen an
Klassen, die Datenbankzugriff benötigen weiterleiten muss).

(2) Ich verwende in der DB-Klasse lauter static-Methoden, was aber unschön ist, da diese ja das rmiServices-
Objekt brauchen welches nur verfügbar ist, wenn ein Objekt der Klasse instantiiert wurde.

Darum meine Frage: Gibt es irgendeine bessere Methode das Problem zu lösen, oder muss ich eine der beiden oben genannten Methoden verwenden?


Grüsse,
--Alex

 

[KSG9|sebastian]

hm..ich würde sagen mit vererbung

also, beispiel:

Du hast folgende Klassen:


A
B
C
D
E
F
G
H



Folgende Klassen benötigen das Objekt rmiServices:


A
B

Dann würde ich es so machen:

public class abc{
    protected rmiServices rmi ;
    public abc(){
        rmiServices rmi = new rmiServices();
    }    
}

class A extends abc{
    public A(){
    super();
    rmi.mach irgendwas
    }
}

class B extends abc{
    public B(){
    super();
    rmi.mach irgendwas
    }
}

 

[Gast]

Hallo KSG9|plak,

danke für Deine Antwort, aber Vererbung ist in meinem Fall leider auch nicht möglich, denn um das rmiServices-Objekt zu erzeugen brauche ich zusätzliche Daten (IP-Addresse und Port des RMI-Servers), die nur in der Applikationsklasse zur Verfügung stehen und somit wäre ich wieder in der gleichen Situation wie vorher, weil ich dann diese Daten weiterreichen müsste.
Ein weiterer Punkt (der allerdings nicht so wichtig ist), wäre, dass ich gerne nur eine Instanz des rmiServices-Objekts hätte.

Weitere Frage:
Wie macht ihr das eigentlich bei der Internationalisierung eurer Applikationen mit den ResourceBundles? Das ist ja eigentlich dasselbe Problem. Das ResourceBundle wird an einer Stelle geladen, dann aber in vielen Objekten der Applikation verwendet.

Grüsse,
--Alex

 

[Xenophon]

Wie wäre es mit einem Singleton, über den jeder Zugriff auf das databaseAccess-Objekt hat?

 

[Gast]

... über den jeder Zugriff auf das databaseAccess-Objekt hat

Das ist eben genau das Problem. Ich müsste das Singleton-Objekt dann entweder durchreichen (siehe (1) meiner ursprünglichen Post) oder den Zugriff über statische Methoden bzw. Objekte regeln (siehe (2) meiner ursprünglichen Post).

Grüsse,
--Alex

 

[bygones]

wieso musst du das Singleton durchreichen ??? genau das musst du beim Singleton eben nicht.
Jede Klasse die die Instanz des SIngeltons braucht holt sie sich einfach per

Singleton.getInstance();

 

[Xenophon]

Ein Singelton sieht so aus:

public class Singleton
{
    protected Singleton()
    {
        super();
        ...
    }

    public static Singleton getInstance()
    {
        if(instance == null)
            this.instance = new Singleton();

        return instance;
    }
    
    private static Singleton instance;
}

 

[bygones]

@Xenophon:
Das ist leider kein Singleton !

1. Du hast einen protected Konstruktor.. Jede Klasse im selben package kann eine neue Instanz erzeugen
2. Das erzeugen der Instanz ist nicht thread sicher
3. Die instanz ist sollte final deklariert werden

Singleton -> http://www.java-forum.org/de/viewtopic.php?t=6090#28141

 

[Xenophon]

@deathbyaclown

1.Eigentlich ist es besser, den Konstruktor protected zu machen (Vererbung).
2.Hast Recht. Ein synchronized mit rein.
3.Die Variable muss nicht unbedingt final sein.

 

[bygones]

@deathbyaclown
Eigentlich ist es besser, den Konstruktor protected zu machen (Vererbung).

Nein - dann ist es kein Singleton !
Singleton ist eine Klasse von der nur eine Instanz erstellt werden kann. Der protected Konstruktor erlaubt es aber mehrere Instanzen zu erstellen. Außerdem sind Singletons nicht für eine Vererbungshierarchie gedacht (warum auch ?)

 

[Xenophon]

Außerdem sind Singletons nicht für eine Vererbungshierarchie gedacht (warum auch ?)

Da fällt mir doch spontan ein CommandProcessor ein. Der sollte als Singleton angelegt werden. In einer einfachen Version führt er nur Commands aus und verwaltet sie auf einem Stack für späters undo. In einer erweiterten Version könnte z.B. noch Logging mit rein.

 

[Gast]

Das wäre dann eben wieder Fall (2) meiner ursprünglichen Post. Ich würde in diesem Fall über statische Methoden auf mein gewünschtes Objekt (rmiServices) zugreifen, das in diesem Fall eben in einem Singleton gekapselt ist. Das Problem ist aber, dass nur ein Objekt, nämlich die Applikationsklasse die Informationen (IP-Adresse und Port des RMI-Servers) hat, um das rmiServices-Objekt korrekt zu erzeugen. Es ist zwar in meinem Fall so, das diese Applikationsklasse als erstes aufgerufen wird und ich demnach davon ausgehen kann das rmiServices-Objekt existiert wenn ich darauf zugreife - darum bin ich eben auch auf (2) als mögliche Lösung gekommen, was ich aber irgendwie nicht ganz sauber finde (oder macht man das normalerweise so?).

Bei einem Singleton ist es doch so, dass die getInstance() - Methode das Singleton instanziiert wenn es noch nicht existiert, oder einfach eine Referenz auf das Singleton zurückliefert, falls es schon existiert. Dabei ist es aber egal, von wo aus die getInstance()-Methode aufgerufen wird.

In meinem speziellen Fall muss der erste Aufruf von getInstance() in der Applikationsklasse erfolgen - das würde eben wieder (2) meiner Ursprungspost entsprechen.

Möglicherweise habe ich hier auch einen Denkfehler - beschäftige mich nämlich noch nicht so lange mit Design Patterns.

Auf dieses Problem stosse ich eigentlich immer, wenn ich beim Start einer Applikation gewisse Objekte (z.B. ResourceBundles zur Lokalisierung, RMI-Objekt, ...) generiere, die dann in weitenTeilen der Applikation verwendet werden.

Hoffe ich habe mich nicht zu umständlich ausgedrückt! :wink:

Grüsse,
--Alex

 

[Xenophon]

In Deinem Singelton definierst Du einfach noch eine get und eine set-Methode für Dein DB-Objekt und schon hast du eine zentrale Stelle, an der jeder das DB-Objekt bekommen kann ("MySingelton.getInstance().getDBObjekt()").

 

[Guest]

Das Zauberwort heisst "Service Locator"