Statische Bindung

[Killit]

Ich hab grad ein Beispiel für dynamische Bindung erstellt:

public class Auto {

Public void ichbin(){

System.out.println(„Ich bin ein Auto“);
}
}

public class Mercedes extends Auto {

public void ichbin(){

System.out.println(„Ich bin ein Mercedes“);
}

public class BMW extends Auto {


public void ichbin(){

System.out.println(„Ich bin ein BMW“);

}
import java.util.List;

public class Test {

private List<Auto> Lol = new ArrayList<Auto>();

public void ausgeben(){

Auto a = new Auto();
Mercedes b = new Mercedes();
BMW c = new BMW();
Lol.add(a);
Lol.add(b);
Lol.add(c);

for( Auto e : lol ){

System.out.println(e.ichbin());

...

Ausgabe:

Ich bin ein Auto
Ich bin ein Mercedes;
Ich bin ein BMW






Ich weiß jetzt nicht genau, wie man ein Beispiel für statische Bindung schreiben könnte bzw versteh ich auch nicht ganz genau, wie das als code aussehen würde.
wenn ich z.B: mit super.ichbin(); aufrufen würde, wäre das ja immer noch dynamisch
kann mir jemand ein gutes Beispiel für statische Bindung schreiben?

 

[faetzminator]

public class Foo {

    static class A {

        String a = "statisch";

        String get() {
            return a;
        }
    }

    static class B extends A {

        String a = "dynamisch";

        @Override
        String get() {
            return a;
        }
    }

    public static void main(String[] args) {
        A a = new B();
        System.out.println(a.get()); // dynamisch
        System.out.println(a.a); // statisch
    }
}

 

[Landei]

Java kann kein Multiple Dispatch. Man könnte das als eine Art statische Bindung auffassen, da ja keine dynamische Bindung stattfindet.

public abstract class Shape {
    
    public void intersects(Shape that) {
        System.out.println(this.toString() + " instersects with a Shape");
    }

    public void intersects(Circle circle) {
        System.out.println(this.toString() + " instersects with a Circle");
    }

    public void intersects(Triangle triangle) {
        System.out.println(this.toString() + " instersects with a Triangle");
    }
    
    @Override
    public String toString() {
        return "Shape";
    }
}

public class Circle extends Shape {
    @Override
    public String toString() {
        return "Circle";
    }
}

public class Triangle extends Shape {
    @Override
    public String toString() {
        return "Triangle";
    }
}

List<Shape> shapes = new ArrayList<Shape>();
shapes.add(new Circle());
shapes.add(new Triangle());
for(Shape s1 : shapes) {
    for(Shape s2: shapes) {
        s1.intersects(s2);
    }
}

Ausgabe:

Circle instersects with a Shape
Circle instersects with a Shape
Triangle instersects with a Shape
Triangle instersects with a Shape

Es wird also immer "statisch" die erste Version von [c]intersects[/c] gebunden, obwohl man dynamisch jeweils eine "besser passende" Version hätte finden können.

Natürlich ist dieses Verhalten hier eher ungünstig. Das "erwartete" Verhalten lässt sich mit Double Dispatch erziehlen.

 

[faetzminator]

Also ich hätte Objektvariablen (bzw. Referenzierungen darauf) als statisch angesehen - wie in meinem Beispiel.

 

[Landei]

Ich denke beide Beispiele sind richtig. Ich wollte etwas zeigen, wo Methoden nicht dynamisch gebunden werden.

 

[faetzminator]

Gut möglich, ja Als 3.: Natürlich gilt die statische Bindung auch für statische Methoden und Variablen.

 

[SlaterB]

nur weil keine Vererbung stattfindet einen Code als Beispiel für statistische Bindung in Java zu verwenden ist etwas kühn,
dann könnte man ja auch im Auto-Beispiel ganz am Anfang die ichbin()-Methoden der Subklassen streichen, ob das akzeptiert wird?

ein derart kompilierter Code kann zur Laufzeit immer noch ausgetrickst werden wenn neue Unterklassen theoretisch erlaubt
und von außen übergeben oder zumindest per Reflection reingemogelt werden können,

eine richtig statische Bindung zur Laufzeit ist meiner Ansicht nach nur der Aufruf statischer + finaler Methoden + Variablen

----

dass zur Kompilierzeit die Signatur der Methode statisch gewählt wird statt Multiple Dispatch ist für sich gewiss interessant,
innerhalb der Java-Gegebenheiten letztlich aber nicht relevant zur aktuellen Frage, da gehts um was anderes