MichiLee

[pgoetz]

Guten Morgen!

[...]

1. Ich könnte die DatasourceFactory ja statisch machen, mit statischen Klassenvariablen zum Beispiel für Parameter und dem Typ ob DB oder XML)

private static String typ = null;
privat static String parameter = null;

Dann könnte man in einer anderen Klasse die Methode init von DatasourceFactory aufrufen, welche die zwei Klassenvariablen füllt mit DatasourceFactory.TYP="DB"
[...]

Das ist eine schlechte Idee, deren Haken Du ja schon selbst erkannt hast. Jedesmal, wenn ein anderer Client die Klasse DatasourceFactory "initialisiert", dann überschreibt er damit für alle anderen Benutzer den zurückgelieferten Datentyp. Wenn also Client 1 mit "DB" anfängt, Client 2 aber dann "XML" verwendet, dann bekommt Client 1 das nächste Mal auch "XML".

(Wenn das eine Applikation im Internetbetrieb wäre, wo mehrere Leute auf die Klassen/Klassenvariable zugreifen, wäre der Inhalt der Klassenvariablen ja egal, da es ja für jeden Benutzer, der auf die Klassenvariablen zugreift ja eh in einem eigenen Thread arbeitet oder? Oder überschreiben die sich irgendwie das hin und her?)

Threads haben hier keinen Einfluss. Wichtig ist die VM. Statische Eigenschaften und Methoden werden pro VM initialisiert. Wie viele Threads in dieser VM arbeiten, ist dabei egal.

Ein sinnvoller Weg ist, das nicht über eine Eigenschaft der DatasourceFactory zu regeln, sondern beim Aufruf der Methode getDatasource() einen Parameter mitzugeben, welchen Typ man gerne hätte.

2. [...]
   Die CommandoDB nutzt dann evtl. die DatasourceFactory von oben um gleich das Kommando auch auszuführen oder gibt anstatt den User nur das Commando zurück, so dass das Model mit dem Commando auf DatasourceFactory zugreift.

Findet ihr diese Lösung akzeptabel? (Unser Lehrer schlug vor, anstatt oben eine DataDB zu haben, dass man das für jede Bereiche einzeln macht, bsp. DataUserDB, DataProjektDB, so dass die einzelnen Klassen dann jeweils einen User laden, editieren, löschen usw.

Das kommt auf den Umfang der Methoden an. Sind es insgesamt nur 5 oder 10 Abfragen, dann kann man das schon in einem Interface abbilden. Aber 10 ist meiner Erfahrung nach schon die absolute Höchstgrenze. Ich bin ein Freund von kleinen und spezialisierten Klassen.

3. [...]
   Ich hätte dann in DataDB die Methode isConnected() eingefügt, kann sie aber nich nutzen, da das Objekt so Datasource test = new DataDB() gebildet wurde und Datasource nicht die Methode isConnected hat?
   Sowas geht dann allgemein nicht ne? Deshalb müsste ich mir von Anfang an überlegen, so dass es nicht so zu Überlappungen kommt ne?

Das geht nur, wenn Du weißt, dass das Ergebnisobjekt von einem bestimmten Typ ist, und Du auf diesen (speziellen) Typ castest. Allerdings sollte das in einem gut entworfenen Modell nicht nötig sein. Das ist ja das schöne an fachlichen Interfaces, dass man sich eben nicht mehr darum kümmert, welche konkrete Implementierung man im Hintergrund serviert bekommt. Versuche, Deine Anwendung so zu schreiben, dass Du keine solchen Hintertürchen brauchst. Die Datasource-Implementierung selbst sollte sich um solche Dinge wie Connection-Management kümmern. Wenn hier ein Fehler auftritt, kannst Du ja eine fachliche Exception werfen, die Du auch im Interface deklarierst. So hast Du immer die Gewissheit, dass auf solche technischen Schwierigkeiten adäquat reagiert werden kann, ohne dass man gleich die Implementierung kennen muss.

Insgesamt gefällt mir Deine Herangehensweise sehr gut. Deine Gedanken machen Sinn und Du beschäftigst Dich intensiv mit dem Thema. Dein konkretes Modell ist ein wichtiges Konstrukt in der objektorientierten Softwareentwicklung und ein weit verbreitetes Design Pattern (eigentlich zwei: Factory und Data Access Object). Mach weiter so!

Schöne Grüße,

Peter