Instantiierung von Interfaces



  • Optimizer schrieb:

    Letzlich kann man das Implementieren von Interfaces auch als Vererbung betrachten, denn nichts anderes ist es. Es können über diesen Weg nur keine Implementierungen vererbt werden, sondern eben nur die Schnittstelle (warum das Ding wohl Interface heißt?).

    Das sehe ich anders. Bei der Vererbung bekommt die Subklasse etwas geschenkt. Sie erbt die Funktionalität der Basisklasse. Bei der Implementierung eines Interfaces bekomme ich nichts geschenkt, im Gegenteil: Ich verpflichte mich dazu, gewisse Verträge zu erfüllen.
    Letztlich aber auch egal. Hauptsache man weiß, wie man es benutzten muss 🙂



  • Du kriegst beim implementieren eines Interfaces auch was geschenkt: Du darfst dich ein ICompareable nennen und dich zu anderen ICompareable's gesellen und dich mit ihnen vergleichen. 🙂

    Wenn du von ner abstrakten Klasse erbst, verpflichtest du dich genauso zu etwas, das ist ja ganz normal bei Vererbung. Ein Interface ist ziemlich gut mit einer rein abstrakten Basisklasse vergleichbar.



  • Optimizer schrieb:

    Gibt sogar mehrdimensionale, die würde ich mir für Java wünschen. Stattdessen kommt dann so ein Schwachsinn: http://www.jcp.org/en/jsr/detail?id=83

    wieso? geht doch:

    String [][]lala = {{"hallo"}, {"doof"}};
    	String [][][]lulu = new String[3][4][5];
    

    jedenfalls mit jdk 1.5



  • net schrieb:

    Optimizer schrieb:

    Gibt sogar mehrdimensionale, die würde ich mir für Java wünschen. Stattdessen kommt dann so ein Schwachsinn: http://www.jcp.org/en/jsr/detail?id=83

    wieso? geht doch:

    String [][]lala = {{"hallo"}, {"doof"}};
    	String [][][]lulu = new String[3][4][5];
    

    jedenfalls mit jdk 1.5

    Das sind Arrays von Arrays.



  • @net: Das ist aber nicht dasselbe.



  • MaSTaH schrieb:

    @net: Das ist aber nicht dasselbe.

    warum nicht? wo ist der unterschied?



  • Dass deine Arrays von Arrays nicht zwangsläufig in innerhalb jeder Dimension die selbe Länge haben. Siehe auch mein ausführlicheres Posting vorhin.



  • Optimizer schrieb:

    Dass deine Arrays von Arrays nicht zwangsläufig in innerhalb jeder Dimension die selbe Länge haben.

    das ist doch nie so bzw. nur wenn man die arrays so anlegt oder täusche ich mich da?. in der praxis spielt es wohl keine rolle ob das programm...
    ...über ein array von pointern geht, die basisadresse eines arrays ermittelt, den index aufaddiert und dann auf eine speicherzelle zugreift
    ... oder die indizes multipliziert um auf den speicher zuzugreifen



  • das ist doch nie so bzw. nur wenn man die arrays so anlegt oder täusche ich mich da?

    Ich meine sowas:

    xxxxxxx
    xxxxx
    xxxxxxxxxxxxx
    xxxxxxxxx
    xxxxxxx
    xxxxxxx
    xxxxxx

    brauchst du sowas häufig? Ich glaube nicht. Also warum nicht dem Compiler sagen, dass dein Feld rechteckig sein soll? Dann kann er dir helfen, Fehler zu vermeiden.

    ...über ein array von pointern geht, die basisadresse eines arrays ermittelt, den index aufaddiert und dann auf eine speicherzelle zugreift
    ... oder die indizes multipliziert um auf den speicher zuzugreifen

    Der JIT-Compiler kann sich mit Sicherheit einige Indexprüfungen schenken, wenn er weiss, dass das Array rechteckig ist.
    Ich wollte es aber eigentlich nicht so technisch begründen, warum diese Arrays gut sind. btw, du kannst nicht sagen, ob da Indizes multipliziert werden, oder ob das anders realisiert wird. Ich glaube, dass der Index geshiftet wird und die Arrays intern immer ne 2er Potenz als Länge haben. Das scheint mir wesentlich performanter zu sein, auch performanter als:
    Index 1 auswerten -> Referenz zum zweiten Array folgen -> Index 2 auswerten.
    Vergleiche mal:

    for( int a = 0;  a < 5;  ++a )
        for( int b = 0;  b < 5;  ++b )
            foo[a][b] = bla;   // Hier muss jedesmal die Länge von foo[a] bestimmt werden, um den Index b zu prüfen.
    
    for( int a = 0;  a < 5;  ++a )
        for( int b = 0;  b < 5;  ++b )
            foo[a, b] = bla;   // Hier ist klar, dass foo[0,] genauso lang ist wie foo[1,]
    

    Aber ich wollte eigentlich auf Sprachebene bleiben. Fakt ist nun mal, wenn du eine Methode hast die so etwas frisst:

    void foo(int[][] rectangularField)
    

    du nicht die Garantie hast, dass das Feld rechteckig ist. Hand auf's Herz: In den allermeisten Fällen wirst du wohl ein rechteckiges Feld brauchen und kein "ausgeschnittenes".

    Außerdem kannst du bei deinem geschachtelten Array so ein Teilarray rausnehmen:

    int[][] foo = new int[50][80];
    int[] x = foo[30];
    

    Vielleicht ist das aber nicht unbedingt gewünscht? Brauchst du diese ganze Flexibilität jedes Mal? Die kriegst du nicht umsonst.
    Mir ist es lieber, wenn mein 2D-Feld EIN Objekt ist.



  • Optimizer schrieb:

    Ich meine sowas....

    ok. das leuchtet ein. danke für die ausführliche erklärung 🙂



  • *lol* gerade entdeckt:

    Java Specification Request schrieb:

    Native Java arrays are strictly one-dimensional. Multidimensional arrays are simulated as "arrays of arrays". That means, for example, that each element of a double[][] array is a double[] array. Arrays of arrays are very general and therefore more difficult to optimize. For instance, for a double[][] a, rows a[i] and a[j] may have different lengths. Bounds checking optimization is an example of an optimization that can be better performed when arrays are known to be rectangular (as in true multidimensional array). Furthermore, the "array of arrays" approach opens up more possibility for aliasing. For instance, for a double[][] a and double[][] b, it is possible that a[i] and b[j] refer to the same row. In fact, it is possible that a[i] and a[j] (i != j) refer to the same row. Many advanced compiler optimizations rely on accurate aliasing disambiguation.

    Ich saug mir was aus den Fingern und es stimmt auch noch. 😃



  • Optimizer schrieb:

    *lol* gerade entdeckt:

    Java Specification Request schrieb:

    Native Java arrays are strictly one-dimensional. Multidimensional arrays are simulated as "arrays of arrays". That means, for example, that each element of a double[][] array is a double[] array. Arrays of arrays are very general and therefore more difficult to optimize. For instance, for a double[][] a, rows a[i] and a[j] may have different lengths. Bounds checking optimization is an example of an optimization that can be better performed when arrays are known to be rectangular (as in true multidimensional array). Furthermore, the "array of arrays" approach opens up more possibility for aliasing. For instance, for a double[][] a and double[][] b, it is possible that a[i] and b[j] refer to the same row. In fact, it is possible that a[i] and a[j] (i != j) refer to the same row. Many advanced compiler optimizations rely on accurate aliasing disambiguation.

    Ich saug mir was aus den Fingern und es stimmt auch noch. 😃

    Sagte ich doch bereits in meinem letzten Posting 😉


Anmelden zum Antworten