Deprecated-API

[Spacerat]

Hallo...
Was ist mir denn da gerade aufgefallen?

// z.B. Component
public void setEnabled(boolean enable)
{
  enable(enable);
}

public void enable(boolean enable)
{
  if(enable) {
    enable();
  } else {
    disable();
  }
}

public void enable()
{
  enabled = true;
  // ... Code zum aktivieren der Component
}

public void disable()
{
  enabled = false;
  // ... Code zum deaktivieren der Component
}

Was es daran zu bemängeln gibt? Ganz einfach: Sun "zwingt" einen dazu, im Zweifelsfalle Methoden zu überschreiben, bei denen von deren Verwendung abgeraten wird. Gesetzt den Fall, ich möchte beim De- bzw. Aktivieren einer Component noch einige Dinge ausführen. Würde ich dazu "setEnabled()" überschreiben, laufe ich gefahr, das irgend jemand (warum auch immer) die anderen Methoden aufruft und meine Zusätze dadurch umgangen werden. Überschreibe ich all diese Methoden, und setze dabei die richtige Reihenfolge (aktuell -> deprecated) endet das in einem Kreisbezug. Was bleibt also? Das überschreiben und damit letztendlich auch die Verwendung misbilligter APIs. Wie seht ihr das?

 

[max40]

Eine Idee wäre, das man zu seinen Programmen eine JRE mit ausliefert, die mit den Programmen getestet ist! Man müsste sich dann evtl. eine Lösung einfallen lassen, wenn man kleine Tools erzeugt, da ein paar KB des eigenen Programms in keinen Verhältnis zur JRE mit 30 MB oder so steht!

 

[didjitalist]

schreib keine ableitung, arbeite mit delegation.

 

[Marco13]

Schonmal einen JTree delegatet? :autsch:
Das eigentliche Problem ist schon länger bekannt. Bin aber gerade nicht 100% sicher, was du mit "Kreisbezug" meinst.... Aber wie auch immer man es löst: Es kommt etwas unschönes dabei raus. Das ist ein Dilemma.

 

[slawaweis]

üblicherweise kann man alle Änderungen in AWT/Swing über Listener rausbekommen, auch Enabled:

[highlight="java"]
addPropertyChangeListener(new PropertyChangeListener() {
@Override
public void propertyChange(PropertyChangeEvent evt)
{
if(evt.getPropertyName().equals("enabled"))
System.out.println(evt.getPropertyName() + " : " + evt.getNewValue());
}
});
[/highlight]

Slawa

 

[Spacerat]

Bin aber gerade nicht 100% sicher, was du mit "Kreisbezug" meinst....

Das hier:

// der richtige Weg:
public void setEnabled(boolean b)
{
  if(enabled ^ b) { // Ich kann das folgende sogar abfangen... Zwecklos...
    enabled = b;
    if(enabled) {
      // Eigene Zusätze zum aktivieren der Component
    } else {
      // Eigene Zusätze zum aktivieren der Component
    }
    super.setEnabled(b);
  }
}

// super.setEnabled() endet in enable() bzw. disable()
// der Richtige Weg wäre die andere Richtung.
// enable() und disable() enden in setEnabled()
// wäre es so, müsste man sich keine Gedanken um den
// folgenden Kreisbezug machen.

public void enable()
{
  setEnabled(true);
}

public void disable()
{
  setEnabled(false);
}

Nun ja... Deprecated heisst ja nicht "veraltet" sondern "misbilligt". Ist es in sofern dann auch ok, wenn ich die misbilligten Methoden nicht überschreibe und denen, die sie (warum auch immer) trotzdem verwenden wollen, ein korrektes De- bzw. Aktivieren verwehre?

 

[Wildcard]

Ist es in sofern dann auch ok, wenn ich die misbilligten Methoden nicht überschreibe und denen, die sie (warum auch immer) trotzdem verwenden wollen, ein korrektes De- bzw. Aktivieren verwehre?

Beides ist eine vertretbare Lösung. Anbieten und Warning unterdrücken, oder nicht anbieten und entsprechend dokumentieren. Meiner Meinung nach kann sich niemand beschweren wenn er grundlos deprecated Methoden verwenden und das dann irgendwann nicht mehr funktioniert, er wurde ja lange genug gewarnt.

 

[didjitalist]

ich würd sie trotzdem überschreiben und in der implementierung einen entsprechenden laufzeitfehler schmeissen.

 

[Wildcard]

ich würd sie trotzdem überschreiben und in der implementierung einen entsprechenden laufzeitfehler schmeissen.

Geht hier aber nicht, da die nicht deprecated API die deprecated API aufruft und es dann nicht mehr funktionieren würde.