Interface mehrfach implementieren

[Glassghost]

Schönen guten Tag

vielleicht hab ich ja nur Tomaten auf den Augen oder aber das was ich will, geht prinzipiell nicht, mal sehen.

Ich versuch mich grad an nem eigenen Compiler. Habe (in etwa) für jedes Nonterminal meiner EBNF eine "accept-" Methode geschrieben, die dann für die Nonterminals auf ihrer rechten Regelseite wiederum die entsprechenden "accept-" Methode(n) aufruft, je nach Regel eben.

Um den Syntaxbaum aufzubauen, liefert jeder "accept-" Methode einen Knoten an den Aufrufer zurück, so dass sozusagen der Parent- Node die Verantwortung hat seine Kinderchen einzusammeln, in etwa so:

acceptCompileUnit
--> acceptComponent : ComponentNode
-------> acceptInterfaceList : InterfaceListNode
-------> acceptMember : MemberNode
------------> acceptType : TypeNode
...

Für jedes Nonterminal gibts ne eigene Node-class, die alle dasselbe IF (NodeIF) implementieren.

Okay, zunächst bin ich mir eben designtechnisch unschlüssig, ob es so gut ist, die Knoten über den Rückgabewert einzusammeln. Prinzipiell würd ich die Verantwortung schon gern in der Methode lassen, die zum Parent gehört, aber den Rückgabewert würd ich gern sinnvoller nutzen. Alternativ wärs eben auch denkbar, den Vater als Parameter mitzugeben und somit die Verantwortung an die "accept-" Methode des Kindknotens weiter zu geben.

Mein eigentliches Anliegen:
Im Moment hat jede konkrete Node - Klasse auch ihre getter / setter Methode(n) für die einzelnen Kindknoten. Was ich jetzt in erster Linie gern wissen würde: Gibt's ne Möglickeit in einem Interface etwa folgende Methode zu definieren:

interface NodeIF {
   void setChild(JoiNodeIF child);
}

und diese dann - bei Bedarf eben auch mehrfach - so zu implementieren (z.B. für meine Klasse ComponentNode):

public class ComponentNode implements NodeIF {
   void setChild(JoiNodeInterfaceList child) {
      this.ifList = child;
   }

   void setChild(JoiNodeMember child) {
      this.member = child;
   }
   
}

Das es SO nicht geht, ist mir schon klar, aber ich wollt eben zum Ausdruck bringen, was ich gern hätte... hoffe das ist mir einigermaßen geglückt.

Vielen Dank für die Hilfe,
Bob

 

[SlaterB]

warum so unsinnig fremde Klassen, warum kein fertiges Programm?
ist doch nicht so schwer..

public class Test2
    implements Lister
{

    public static void main(String[] args)
    {
        Test2 test = new Test2();
        ArrayList l = new ArrayList();
        test.doList(l);
        List l2 = l;
        test.doList(l2);
        
        Lister test2 = test;
        test2.doList(l);
        
    }

    public void doList(ArrayList list)
    {
        System.out.println("ArrayList: " + list);
    }

    public void doList(List list)
    {
        System.out.println("List: " + list);
    }

}


interface Lister
{

    public void doList(List list);
}

zu beachten ist, dass in meinem Beispiel zweimal die allgemeine Operation benutzt wird,
obwohl es immer die Unterklasse ArrayList ist,

wenn man das ganze also allgemein einsetzt, werden deine mehreren Operationen nicht genutzt

 

[Guest]

Hallo SlaterB,

danke für die schnelle Antwort.

warum so unsinnig fremde Klassen, warum kein fertiges Programm?

Sorry, aber ich versteh nicht, was Du mit "...unsinnig fremde..." und "... fertiges Programm?" meinst.

ist doch nicht so schwer..

Tja, das hängt halt immer von den Fähigkeiten des Einzelnen ab.

Danke auch für dein Codebeispiel, ich glaube mir ist dadurch klar geworden, dass das, was ich gerne hätte , wohl doch nicht geht...

Denn wenn ich mich nicht irre, wird beim Aufruf in Zeile 15 dann der Code von

public void doList(List list)

ausgeführt.
Ich hätt's halt gern, dass aufgrund des Typs des Parameters (in diesem Fall ist der Typ ja ArrayList) die entsprechende Methode gewählt wird (das ginge natürlich, wenn man das Interface weg liese, überladen halt, aber ich brauch das IF zum Syntaxbaum traversieren). Da aber der Typ von "test" Lister ist, wird logischerweise die Implementierung des Interfaces ausgeführt... wenn ich dort jetzt eine Operation von ArrayList ausführen wollte, müsst ich erst wieder auf den Typ prüfen und entsprechend casten...


Danke trotzdem,

Bob

 

[SlaterB]

was du da in den letzten Zeilen beschreibst, wird in meinem Programm ganz deutlich,

und dafür brauch man eben keine seltsamen eigenen Interfaces,
List und ArrayList tun es genauso, die kennt jeder,

und was gibts an 'fertiges Programm' nicht zu verstehen?
meins ist fertig, einfach kopieren, laufen lassen, deins nicht

wenn du so ein Programm wie meins geschrieben hättest,
wären dir vielleicht schon die Fehler aufgefallen,
oder ich hätte nur noch den einzigen intelligenten Teil

        Test2 test = new Test2(); 
        ArrayList l = new ArrayList(); 
        test.doList(l); 
        List l2 = l; 
        test.doList(l2); 
        
        Lister test2 = test; 
        test2.doList(l);

hinzufügen müssen,

dann ginge es also viel schneller voran in der Fragebearbeitung

 

[Guest]

Hallo nochmal,

was du da in den letzten Zeilen beschreibst, wird in meinem Programm ganz deutlich

stimmt, klar wird's deutlich, drum hab ich mich ja auch bei Dir bedankt, denn erst durch dein Programmbeispiel bin ich da drauf gekommen :toll:
Manchmal brauch ich einfach jemanden, der den nötigen Abstand hat und der mir das eigentlich Offensichtliche dann vor die Nase hält, in dem Fall hast Du mir den Gefallen getan, danke nochmal.

und dafür brauch man eben keine seltsamen eigenen Interfaces,
List und ArrayList tun es genauso, die kennt jeder,

Naja, ich hab mich da halt für ein eigenes Interface entschieden, was mit dem etwas umfangreicheren Gesamtkonzeot des Compilers und der Aufgabenstellung zu tun hat. Allein die Traversierung nach dem Visitor pattern schien mir bei der Entwurfsentscheidung dadurch einfacher, vielleicht war das eine Fehlentscheidung, ich werd's überdenken. Danke trotzdem für deinen Einwurf es mit ArrayList bzw. List zu versuchen.

und was gibts an 'fertiges Programm' nicht zu verstehen?
meins ist fertig, einfach kopieren, laufen lassen, deins nicht

Hmm.. sorry, aber ich kann allgemein deinen scharfen Ton nicht nachvollziehen, ich wollt Dich auf keinen Fall angreifen, ich hab deinen Satz einfach im Kontext nicht verstanden, wenn Du Wert auf eine "Komplettheit" bei den Codeabschnitten legst, solltest Du das auch bei den textuellen Teilen tun und in ganzen Sätzen schreiben, dann gibt's da vielleicht auch weniger Missverständnisse

wenn du so ein Programm wie meins geschrieben hättest,
wären dir vielleicht schon die Fehler aufgefallen,

Da ist bestimmt was dran, ich mach's beim nächsten Mal bevor ich mich hier wieder ins Forum begebe.

Ansonsten gibt's meiner Meinung nach keinen Grund für Sarkasmus.

Bob

 

[SlaterB]

> Da ist bestimmt was dran, ich mach's beim nächsten Mal bevor ich mich hier wieder ins Forum begebe.


das ist alles was ich erreichen wollte