Eclipse Projekte den BuildPath hinzufügen - Bester Weg?

[Volvagia]

Ich weiß nicht, aber ich glaube ich steh gerade tierisch auf dem Schlauch. :/
Ich habe ein Projekt, in dem mehrere andere voneinander unabhängige Teile eingebaut werden können/sollen. Dieser brauchen nur sozusagen als "Eingangsklasse" von einer anderen zu erben. Auf grund der möglichen Größe dieser Teile wollte ich ein eigenes Workset dafür anlegen, und jedes in ein eigenes Projekt legen. Jetzt kann es aber auch sein, dass diese Teile wiederrum wieder mit Klassen für andere Aufgaben kommunizieren müssen. Dadurch müsste ich aber die beiden Projekte sich gegenseitig im Build-Path adden, was aber ja nicht geht.
Die einzige Möglichkeit, die mir sonst noch eingefallen ist, wäre, diese 3. Klassen in ein zusätzliches Projekt zu legen, und dieses wiederrum allen hinzuzufügen.

Gibt es da eventuell noch einen besseren Weg, das zu lösen? 🙂

 

[Wildcard]

Abhängigkeiten dürfen eigentlich immer nur in eine Richtung gehen, von Oben nach Unten. Sprich, die höhere Schicht kennt die tiefere, nicht anders herum. Das gilt sowohl auf Klassen, als auch Package und Projekt Ebene. So verhinderst du zirkuläre Abhängigkeiten.

 

[Volvagia]

Ich habe es derzeit in etwa so:

Soll ich es so machen?
Oder gibt es da einen besseren Weg?

Wie meinst du das mit der Abhängigkeit bei Packages?
Wenn ich es jetzt so habe:

Projekt
------GUI
------------GUI-Logik
------Logik
------Teile
------------Teil 1
------------Teil 2
------------Teil 3

Dann wäre es ja nicht möglich, dass ein Teil tatsächlich auf die Logik zugreift.
Dazu müsste es doch so aussehen:

Projekt
------GUI
------------GUI-Logik
------Teile
------------Teil 1
------------------Logik
------------Teil 2
------------------Logik
------------Teil 3
------------------Logik

Wodurch wieder die Wiederverwendbarkeit flöten geht. ???:L

 

[Paeddah]

Hiho und - noch - guten Morgen!

Nach etwas grübeln, habe ich dein Problem verstanden. Auch wenn es mir so vorkommt, als wenn du einen design-technischen Fehler hast. Es kommt mir etwas spanisch vor, dass ein Teil direkt auf die GUI-Logik zugreifen muss. Ggf. solltest du hier über einen Controller oder ähnliches nachdenken.

Sei's drum. Zu deinem ursprünglichen Problem.

Du musst die Abschnitte deines Programmes, die sowohl von den Teilen als auch der restlichen Logik/Implementierung verwendet werden sollen in ein eigenständiges Projekt auslagern.

IMHO verwendest du am Besten in dem "mittleren" Projekt nur Interfaces / ggf. abstrakte Klassen.
Das

Teil

-Interface erhält dabei set-Methoden für die Interfaces von

Logik

und

GUILogik

.

So hast du - grob gesprochen, die drei Projekte:

• A - Enthält GUI, Programm und die Implementierung von Logik und GUILogik
• B - Enthält die Interfaces für Teil, Logik und GUILogik
• C1..n - Enthält die Implementierung von Teil n

Dabei "kennt"

• A: B und C
• B: Nichts
• C: Nur B

Um das eventuell noch deutlicher zu machen noch ein kleines Diagramm - ja nicht 100% konform ich weiss :bae: -:

Grüße

Päddah

 

[Volvagia]

Tut mir leid, dachte ich habe es einfach erklärt.
Ich weiß nur nicht, wie ich die Interface benutzen soll. Ich habe sie bisher nur benutzt, um eine beliebige Klasse zu übergeben, um sicherzugehen, dass darin eine Methode existiert.

Ums noch ein wenig zu erklären:

Die GUI sind natürlich GUI-Elemente für das Programm. Die GUI-Logik sind Elemente, die benötigt werden, um die Teile anzuzeigen. Die Mainklasse der Teile erbt von einer abstrakten Klasse, die von JComponent erbt, um sie einzubinden wird eine Instanz erzeugt, und einer Controllerklasse übergeben bzw. durch eine andere Methode wieder ausgeworfen. Die Logik enthält Klassen, die die von den Teilen benutzt werden können, um gewisse Aufgaben zu erfüllen, aber nicht müssen.

 

[Paeddah]

Hi!

Wie du schon selbst geschrieben hast, sicherst du mit den Interfaces nur ab, dass gewisse Methoden existieren.

Du programmierst in deinen

Teil

-Implementierungen gegen die Interfaces von

Logik

und

GUILogik

. Kümmerst dich also an der Stelle nicht um die konkrete Implementierung.

Kleines Beispiel:

public class Teil1 implements Teil {

  // .. Kram und Variablen

  @Override
  public void setLogik(Logik logik) {
    this.logik = logik
  }

  @Override
  public void someMagicMethod(Object magicParameter) {
    // Do something magic
    logik.methodOfLogik(magicParameter);
    // More Magic
  }
}

  public class Programm {
    public void myMethod() {
      Teil t = new Teil1();
      t.setLogik(new LogikImpl);
      Object o ....
      t.someMagicMethod(o);
    }
  }

public class LogikImpl implements Logik {
 
  @Override
  public String methodOfLogik(magicParameter) {
    // Methode, die durch Logik implementiert werden muss.
  }
}

Der Vorteil ist, dass du die

Logik

-Implementierung(en) austauschen kannst ohne an den

Teil

-Implementierungen was ändern zu müssen. Und, deiner Anforderung nach getrennten Projekte wird genüge getan.

Hoffe, dass das den Sachverhalt etwas verdeutlicht hat.

Grüße

Päddah

 

[Volvagia]

Vielen Dank. 🙂
Mir ist jetzt aber noch eingefallen, dass es eigendlich ein Applet werden soll. Deshalb weiß ich nicht, wie ich Bilder aus den ausgelagerten Projekten laden soll. :bahnhof: