Designproblem

Java-Forum Allgemeine Themen
1

Hey Leute.
Ich hab ein folgendes Problem.
Gegeben seien die Klassen A, B, C und die Library EpicLib.
(Es ist wieder mal was mit lwjgl, aber ich machs mal so abstrakt wie möglich)

A, B, C sind alle Bindable. Das heißt ich kann Objekte aller 3 Klassen binden und unbinden,
allerdings halt auf 3 verschiedene weisen: EpicLib.epicBindStyleA(), …B(), …C().
Gut, mach ich halt Interface mit den oben genannten methoden.

Gefällt mir aus 2 Gründennd nicht: ich will in den Bindables eine statische Methode haben,
A.unbind(), B.unbind()…, um alles unzubinden, auch wenn ich kein Objekt hab von dem ich
weiß das es gebindet ist. Außerdem sieht die bind methode teilweise bei allen gleich aus, zb:
if(A.current != this.current) bind();, analog für B und C, aber halt mit unterschiedlichen bind methoden.
Lässt sich super in einer abstrakten klasse schreiben, (bind() ist dann die abstrakte methode), aber das unbind() müsste
ich dann in jeder der bindable klassen speziell schreiben, auch wenn es prinzipiell das gleiche ist. (nur anders :D)
Und doppelter Code ist hässlich…
Hier würde es doch so viel Sinn machen, in einer abstrakten Klasse
vorzuschreiben, dass die erbende Klasse diese statische methode implementieren soll…

wie würdet ihr das machen?

*** Edit ***

Genau, das current ist ja auch statisch… wieder in jeder der Klassen ein eigenes mal…
moment, dann fällt ja die variante mit der abstrakten klasse auch komplett weg…
mist. was gibts da für ne lösung?

2

wie wäre das? (ungetestet…)

    private final T bindable;
    private Unbinder(T bindable){
       this.bindable = bindable;
    }
   
    public void unbindFrom(BindingTarget target){
     // do common stuff
     doSpecificUnbinding(bindable, target);
   }
   abstract protected void doSpecificUnbinding(T  bindable, BindingTarget target);
  }

//Anwwendung
 new Unbinder<A>(myAObject){
  @ Override
  protected  void doSpecificUnbinding(A bindable, BindingTarget target){
    // do specific binding for A
  }
}.unbindFrom(myBindingTargetObject);```

bye 
TT
3

Ebenso wie TT das gemacht hat, nur mit dem Unterschied, dass ich das Bindable-Interface gleich mit in die abstrakte Klasse integriere. Der Nachteil wäre dann aber, dass “Bindables” keine anderen Klassen mehr erweitern können, ansonsten sind Interfaces ja auch nichts anderes als abstrakte Klassen.

  private static final Bindable CURRENT[] = new Bindable[1]; // so kann auf CURRENT synchronisiert werden, während sein Inhalt verändert wird ;)

  protected abstract void doThings();
  protected abstract void bind();
  protected abstract void unbind();

  public static void bind(Bindable b) {
    synchronized(CURRENT) {
      if(CURRENT[0] != b) {
        if(CURRENT[0] != null) {
          CURRENT[0].unbind();
        }
        b.bind();
        CURRENT[0] = b
      }
    }
  }

  public static void unbind() {
    synchronized(CURRENT) {
      if(CURRENT[0] != null) {
        CURRENT[0].unbind();
      }
      CURRENT[0] = null;
    }
  }

  public static void doThings() {
    synchronized(CURRENT) {
      if(CURRENT[0] != null) {
        CURRENT[0].doThings();
      }
    }
  }
}```
4

Hm, ginge das in Java8 nicht auch mit Interface mit default-Methoden? Die klasse die das Interface implementiert müsste dann nur die Speichervariable für das Binding zur zur Verfügung stellen, währen bind und unbind im Interface implementiert werden?