Objekte m. versch. Interf. dynamisch erzeugen

[HighFish]

Hallo,

hat hier vielleicht jemand zu folgendem Problem eine Lösung?

Bei meinem aktuellen Projekt, einer Art Patientendatenverwaltung, habe ich eine bisher für mich nicht lösbare technische Schranke zu überbrücken:
Es existieren ca. 30 verschiedene Patientendaten, welche über ein oder mehrere Interfaces angesprochen werden sollen, davon existieren bisher fünf, aber es ist durchaus nicht ausgeschlossen, dass noch weitere hinzukommen. Die Interfaces können in jeder erdenklichen Kombination auftreten, d.h. ich muss im Extremfall 30 verschiedene Klassen für alle erdenklichen Interfacekombinationen schreiben, in der Praxis kann ich diesen Wert auf vielleicht 10 senken, was mir immer noch zu viel ist. Kennt jemand eine Möglichkeit wie ich Objekte mit beliebigen Interfaces zur Laufzeit erzeugen kann?

MfG,

M.W.

 

[Beni]

• Wieso nicht einfach eine Klasse Patient, die alle Interfaces gleichzeitig implementiert? Wenn man A, B, C implementiert, hat man auch gleich die 7 Kombinationen (A) - (B) - (C) - (A, B) - (A, C) - (B, C) - (A, B, C) geschrieben.
  
• Also wenn diese Interfaces klar getrennt sind, kannst du die Patienten vielleicht wie "Behälter" aufbauen:
  Anstelle von diesem:
  

  public class Patient implements A, B, C, D, E, F, G

  
  Dieses hier:
  

  public class Patient{
    private A a = null; 
    private B b = null;
    [...]
  
    public A getA(){ return A; }
    public void setA( A a ){ this.a = a; }
  }

  
  
• Oder vielleicht was mit Delegates:
  

  public class Patient implements A, B, C, D, E, F, G{  // alle bekannten Interfaces
    private A delegateA = null;
    private B delegateB = null;
  
    [...]
  
    public boolean doSomethingOfA( int x ){
      return delegateA.doSomethingOfA( x );
    }
  }

• Vielleicht ist auch das Design komisch, und man kann es mit weniger Interfaces lösen.

 

[desert pinguin]

Ich bin nicht sicher, aber schaue mal Dynamic Proxy an.

 

[HighFish]

Vielen Dank für Eure Tips, trotzdem habe ich dass Projekt gerade gekippt und greife voller Trauer zu Visual C++...

 

[Grizzly]

Vielen Dank für Eure Tips, trotzdem habe ich dass Projekt gerade gekippt und greife voller Trauer zu Visual C++...

Ich programmiere ja jetzt schon seit einiger Zeit OO. Aber von so einem Problem hab' ich noch nie etwas gehört. Warum soll ein Patient mehrere Interfaces haben bzw. soviele? Mir ist der Sinn dahinter irgendwie nicht klar. :bahnhof:

 

[macfreakz]

naja! Java KANN eigentlich fast ALLES, was es der Datenverarbeitung angeht!!!

Du, sollst mal dein Design überarbeiten. So viele Interfaces für ein Objekt habe ich noch nie gesehen!

 

[HighFish]

Es ist durchaus möglich, dass ich falsche Designentscheidungen getroffen habe, aber nach einer Reanalyse kristallisierte sich heraus, dass wir uns bei den Arztpraxen zu > 90% mit Windows-PC's herumschlagen müssen. Das das Programm grafisch eher aufwändig werden wird, habe ich mich nun nach längerer Prototypenentwicklung gegen Java entschieden, da Swing schlicht und einfach nicht leistungsfähig bzw. die Leistung nicht in vernünftiger Zeit realisiert werden kann.

Warum mehrere Interfaces?

Patientendaten können folgendes sein:

• String

• Datum

• Enumeration

• Bool

• Integer

• Double

• Document

• Zusammengesetzte Objekte

Patientendaten können folgende Funktionalität haben:

• Observer

• Observable

• Restricted - d.h. mit festem Eingabebereich

• Measured - mit Maßeinheit

• MultipleMeasured - mit x Maßeinheiten (umrechnung)

Das alles muss über ein Über-Interface angesprochen werden da x versch. Algorithmen für y versch. Risiken auf die Daten angewandt werden können.

Eigentlich habe ich den Job nur unter der Prämisse angenommen das ich mich in Java einarbeiten kann (ca. 1 Jahr Java-Erfahrung) muss aber jetzt erkennen, dass JAVA schlicht und einfach das falsche Tool für dieses Projekt.

 

[Isaac]

Sorry, ich mache den ganzen Tag nichts anders als C++ Code nach Java zu portieren und oft auch andersrum. Es gibt nichts das man in C++ machen kann was man nicht auch in Java machen könnte. Eine Ausnahme gibt es, das ist die Treiberentwicklung. Aber hier muss man klar sagen das Java dafür eben auch nicht gemacht ist. Es würde der Philosophie wiedersprechen. Wenn die Swing zu langsam ist nutze SWT, das sind nur widgets und zeichnen sich nicht komplett selbst.

Das hat auch garnichts mit Java zu tun. Das obige gilt auch für Visual Basic, Pascal und die 100 anderen Programmiersprachen da draussen (abgesehen von den extrem zweckspezifischen Sprachen wie z.b. VHDL)


Würde mich mal interesieren wie du das in C++ gelöst hast. Vieleicht wird dein eigentliches Problem auch durchsichtiger.

 

[Heiko]

Wenn die Swing zu langsam ist nutze SWT, das sind nur widgets und

Ich denke du meinst AWT, oder?

 

[Isaac]

Nein ich meine SWT

 

[HighFish]

Hmm, ich sprach von der Leistungsfähigkeit von Swing, nicht von der Performance. Es macht halt deutliche Unterschiede ob ich für die Oberflächenentwicklung einer Form (man erlaube mir diesen Ausdruck für JPanel) acht oder eine halbe Stunde brauche.
Warum SWT? Damit entscheide ich mich genauso gegen Plattformunabhängigkeit als würde ich das Projekt in C++/C# umsetzen.
Der Unterschied zwischen der jetzt geplanten Version auf .NET-Basis und dem Java-Prototyp liegt in der herangehensweise: da ich in Visual Studio, für meinen Geschmack, eine bessere Unterstützung für die UI vorfinde werde ich das Projekt in Top-Down-Manier entwickeln d.h. ich kann ein paar der Interfaces weglassen, da ich z.B. eine Überprüfung des korrekten Eingabebereichs auch direkt über die GUI machen kann.
Java ist in vielen Belangen sicher die z.Zt. beste Programmiersprache (in C# muss ich mich gerade einarbeiten, deshalb kann ich darüber noch nichts sagen), aber die GUI-Entwicklung ist halt doch sehr lästig.

 

[Grizzly]

Irgendwie werde ich das Gefühl nicht los, dass Du ein Programmieranfänger bist. Wie Du die Interfaces verwenden möchtest, kommt mir sehr merkwürdig vor: Ich habe noch nie gesehen, dass das Wertebereich eines Objektes über ein Interface geregelt wurde.

Was Du an der Leistungsfähigkeit bzw. am Leistungsumfang der Swing auszusetzen hast, verstehe ich nicht (bei der Perfomance hätte ich es eher verstanden ).
Die SWT gibt es übrigens auf so ziemlich jeder Plattform, auf der es auch die Swing gibt.

Du solltest Dir vielleicht mal den JBuilder von Borland anschauen. Der dürfte Deinen Anforderungen entsprechen. Oder Du installierst Dir Eclipse und das Visual Editor PlugIn.