Instantiierung von Interfaces



  • Angren Aldaron schrieb:

    Das heißt, man beschränkt sich selbst nur auf das Interface. Wäre es nicht genauso gut mit den Modifikatoren private und protected zu arbeiten? Also eben alle Methoden und Felder der Klasse als private zu deklarieren und das Interface als public.
    Müsste doch dann den gleichen Effekt haben? Denn dann kann ich doch auch nur noch auf das Interface zugreifen.

    ääääh jein...
    die methoden eine interfaces sollten immer public o.ä sein. ist in java, glaube ich, per default so. in c# bestimmt auch (ist ja von java abgekupfert)



  • net schrieb:

    Angren Aldaron schrieb:

    Das heißt, man beschränkt sich selbst nur auf das Interface. Wäre es nicht genauso gut mit den Modifikatoren private und protected zu arbeiten? Also eben alle Methoden und Felder der Klasse als private zu deklarieren und das Interface als public.
    Müsste doch dann den gleichen Effekt haben? Denn dann kann ich doch auch nur noch auf das Interface zugreifen.

    ääääh jein...
    die methoden eine interfaces sollten immer public o.ä sein. ist in java, glaube ich, per default so. in c# bestimmt auch (ist ja von java abgekupfert)

    Japp. Wenn du die Methoden eines Interfaces nicht explizit definierst, müssen sie public sein. Is ja auch logisch.



  • Also ob die Methoden öffentlich sein sollen, ist wohl eher Anwendungsfall, aber im Grunde hatte ich doch recht, oder nicht. Ihr macht das mit dem Instanzieren des Interfaces der Klasse doch nicht anders.

    Gruß

    Markus Seidl

    PS: Und Java ist ebenfalls wieder irgendwo abgekupfert. Is aber normal. Man behält was gut ist, und tauscht aus was schlecht ist. Innovation. In Novus. Nicht Neu. Nicht KOMPLETT neu



  • Angren Aldaron schrieb:

    Also ob die Methoden öffentlich sein sollen, ist wohl eher Anwendungsfall

    Ich glaub du verstehst nicht ganz: Die Sichtbarkeit von Methoden, die du aus einem Interface implementierst MÜSSEN public sein (mal abgesehen von der von mir oben dargelegten Ausnahme).

    PS: Und Java ist ebenfalls wieder irgendwo abgekupfert. Is aber normal. Man behält was gut ist, und tauscht aus was schlecht ist. Innovation.

    Eher Evolution 🙂



  • interpreter schrieb:

    entelechie schrieb:

    der cast is quatsch; das geht auch ohne.
    analog zu java und c++ (und zich anderen sprachen wahrscheinlich auch).

    Gut! Dann ist das Buch Schrott 👎
    Dann finde ich jetzt eigentlich nur noch die Arrays in C# hässlich 😉

    Was stört dich an denen? 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

    Jojo, über die Verbohrtheit, mal an der Sprache was zu verbessern, kann ich wirklich nur staunen. 🙄



  • Optimizer schrieb:

    interpreter schrieb:

    entelechie schrieb:

    der cast is quatsch; das geht auch ohne.
    analog zu java und c++ (und zich anderen sprachen wahrscheinlich auch).

    Gut! Dann ist das Buch Schrott 👎
    Dann finde ich jetzt eigentlich nur noch die Arrays in C# hässlich 😉

    Was stört dich an denen? 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

    Jojo, über die Verbohrtheit, mal an der Sprache was zu verbessern, kann ich wirklich nur staunen. 🙄

    Findest du so etwas schön:
    foo[][,,,][,] bar;

    Generell finde ich diese Schreibweise mit den Kommata sehr ungewohnt. Im Großen und Ganzen gefällt mir die Sprache dennoch sehr 🙂



  • foo[][,,,][,] bar;

    Leichte Übertreibung, oder? Wofür brauchst du ein Array von 4dimensionalen Arrays von 2dimensionalen Arrays?

    Fakt ist doch, dass man häufig solchen Code hat.

    int[][] myArray;
    

    Jetzt kann man das Ganze rechteckig machen (dass das in C# nur über Umwege geht, ist wohl Absicht). Ich könnte aber jetzt z.B. dem foo[3] ein Array mit Länge 5 zu weisen und dem foo[4] eins mit Länge 31. Allein schon, weil man das aber so selten braucht, finde ich es sinnvoll, mehrdimensionale Arrays anzubieten und nicht nur "Arrays von Arrays".
    Man kann jetzt einfach ein mehrdimensionales Array erstellen, das schaut doch auch nicht schlechter aus.

    int[,]
    

    Jetzt ist aber klar, dass dieses Array immer "rechteckig" ist. Das gibt dem JIT-Compiler zusätzliche Möglichkeiten zur Optimierung, es ist für den Programmierer klarer, dass es sich um ein rechteckiges Feld handelt. Wenn meine Methode Arrays vom Typ foo[,] annimmt, dann ist sichergestellt, dass das Array rechteckig ist. Es ist immer gut, wenn man dem Compiler möglichst genau sagen kann, was man machen will.



  • interpreter schrieb:

    Angren Aldaron schrieb:

    Also ob die Methoden öffentlich sein sollen, ist wohl eher Anwendungsfall

    Ich glaub du verstehst nicht ganz: Die Sichtbarkeit von Methoden, die du aus einem Interface implementierst MÜSSEN public sein (mal abgesehen von der von mir oben dargelegten Ausnahme).

    Öhmmmmmm...... Ja........ natürlich müssen die öffentlich sein, habe aber auch nie was anderes behauptet. Vielleicht mein Fehler, dass es falsch verstanden wurde. Ich meinte nie die Methoden aus dem Interface, sondern die aus der Klasse. Sorry für das Missverständniss. War mir von Anfang an klar, dass wenn man ein Interface hat, die Dinger natürlich öffentlich sein müssen. Mach ja sonst wirklich keinen Sinn.

    Was ich eigentlich meinte: Ich beschränke mich selbst damit, dass ich nur die Referenz auf das Interface einer Klasse nehme.

    Weiterhin meinte ich eigentlich: Es wäre doch das gleiche, wenn ich da nix instanziere/referenziere (meinetwegen auch gebäre), sondern die Klasse mit den Interface erstmal so lasse, und die Methoden innerhalb der Klasse (nix Interface) alle auf private setze, meinetwegen auch protected, damit die gebärten Klassen auch noch darauf zugreifen können.

    Denn dann könnte ich ja immer noch über das Interface (dessen Methoden und Variablen auf Public sind), auf die Private Methoden der Klasse zugreifen.

    Ich hoffe ich konnte jetzt damit alle Missverständnisse aus der Welt schaffen. Sorry wenn ich mich nicht immer ganz klar Ausdrücke. Bin noch am lernen. Ich hab mir jetzt dafür einen 954 Seiten Schinken geholt. Vielleicht kennt das einer. "Visual C# - Grundlagen, Programmiertechniken, Windows-Programmierung" (von Frank Eller und Michael Kofler) Bin bis jetzt zufrieden und selbst das mit den Events habe ich langsam mit dem Buch raus.

    Also Sorry Community, wenn ich dir Aufgrund meiner Unwissenheit auf die Nerven gehe. Dies ist allerdings meine erste Sprache, bei der ich mal wirklich versuche, mich einzuarbeiten.

    Gruß

    Markus Seidl



  • mhm, aber der sinn dabei, klasseninstanzen interfacereferenzen zuzuweisen, besteht ja nicht darin, sich möglichst viel einzuschränken. (das würde man dann wirklich über private-deklarationen lösen, wie du gesagt hast) der sinn besteht ja aber eher darin, dass man objekte ganz unterschiedlicher klassen, die aber das gleiche interface implementieren in der selben referenzvariablen speichern kann, wenn man dann sowieso nur methoden aus dem interface ausführen will. das hat oft vorteile.



  • Jop. Eine Klasse, die das Interface implementiert , ist vom Typ [Interface].
    Damit wird versucht, Mehrfachvererbung ohne die üblichen Nachteile nachzubilden.
    Ich kann ein Auto und ein Haus Objekt haben. Wenn sie beide vom Typ "ICompareable" sind, kann ich sie vergleichen und sortieren.

    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?).



  • 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 🙂


Anmelden zum Antworten