Vererbung - Anpassen von Feldtypen!?

[diggaa1984]

hi,

ich glaub zu wissen, dass man das nicht wirklich machen sollte, aber ich habe folgendes "Problem":

Ich habe eine Klasse ContextFreeGrammar, welche eine kontextfreie (Typ2 der Chomsky-Hierarchie) Grammatik G darstellt (G = (SIGMA, M, R, S))

ich speicher mir in der Klasse folgendes ab:
********************************

• List<String> für nicht-Terminalsymbole (M)
• Hashtable<String,Liste<String>> (also zu jedem M eine Menge von erlaubten Ableitungen/Alternative)
• Liste der Terminalsymbole, welche innerhalb der Alternativen auftreten (Elemente aus SIGMA*)
• zusätzlich noch ein Startsymbol der Grammatik, sowie ein Marker, welche die Terminalsymbole umgibt, damit ich diese von nicht-Terminalsmbolen unterscheiden kann

[HIGHLIGHT="Java"]
public class ContextFreeGrammar {

private List<String> nonTerminals;

private List<String> terminals;

private Hashtable<String,List<String>> rules;

private String startSymbol;
private char terminalMarker;

[...]
[/HIGHLIGHT]

So dass ist als Grundgerüst schon ganz brauchbar, doch ich beziehe mich im weiteren Programmverlauf auf 2 verschiedene Notationen für Typ2-Grammatiken. Zum Einen die BNF-Notation (Backus-Naur-Form), welche ich aus externen Datein einlese die der Nutzer angeben kann; und zum Zweiten die CNF (Chomsky-Normal-Form), welche ich erhalte, wenn ich die BNF mit einem Algorithmus umwandel. Die CNF wird verwendet um die BNF-Grammatiken mit einem universellen Parser zu parsen, sodass ich jede Typ2-Grammatik mit ein und dem selben Parser parsen kann (erleichtert Erweiterbarkeit für neue Grammatiken). Die CNF hat nun einige Restriktionen was die Regelmenge der Grammatik angeht.

Man kann nur Regeln folgender Form angeben:

M => Terminalsymbol
M => NichtTerminalsymbol1 NichtTerminalsymbol2

Im Gegensatz zu BNF gibt es also keine Alternativen mehr pro Nicht-Terminalsymbol. Das bedeutet das auch meine Listen-Datenstrukturen als solche überflüssig werden und ich normale Strings verwenden könnte.

Die CNF wäre also eine spezielle Notation der kontextfreien Grammatiken. Und nun dachte ich, man könnte hier mit Vererbung arbeiten und die List-Strukturen mit Strings überdecken, aber das ist wohl "dirty-style" oder?!

Da ich später über CNF parsen möchte, wäre es vielleicht effektiver nicht 1-elementige Listen zu verwenden sondern auf Strings zuzugreifen.

Also wesentlicher Unterschied: BNF = Listen von Alternative ... CNF = 1 Alternative bestehen aus 1 String (1 Terminalsymbol oder 2 nicht-Terminalsymbole in Folge).

Wie lös ich das nun am dümmsten !? Am besten gar keine Oberklasse verwenden und 2 Klassen (ContextFreeGrammarBNF und ContextFreeGrammarCNF) erstellen?

 

[Gast2]

Moin,

[...alptraum-fach gekürzt]
Am besten gar keine Oberklasse verwenden und 2 Klassen (ContextFreeGrammarBNF und ContextFreeGrammarCNF) erstellen?

wenn sich die Datenhaltung der beiden Strukturen so extrem unterscheidet, macht Vererbung keinen Sinn ... also zwei Klassen ... Du kannst ja dann jeder Klasse eine Methode mitgeben um in die andere Form übergehen zu können

hand, mogel

 

[diggaa1984]

[...alptraum-fach gekürzt]

naja, im Nachhinein war das noch die leichteste Thematik, spät nach Compilertechnik und Parser-kloppen versteht was es mit Grammatiken auf sich hat ^^

Aber damals in theoretischer Informatik war das auch irgendwie alles nur Bahnhof

 

[hdi]

Ich würde sagen 2 Klassen (ContextFreeBNF/CNF) und 1 Interface Grammar.
(falls es wenigstens 1 Gemeinsamkeit gibt, die dir irgendwo nützlich sein könnte)

 

[diggaa1984]

ja hab ich auch grad so gelöst .. die einzige gemeinsamkeit, wären public methoden sowie die Nötigkeit eines Startsymbols und der Nötigkeit des Markers für Terminalsymbole

=> [HIGHLIGHT="Java"]
package grammar;

import java.util.List;


/**
*
*
*
* @author Digger
* @version 0.1
*/
public abstract class Grammar {

protected String startSymbol;
protected char terminalMarker;

/**
*
* @param startSymbol
* @param terminalMarker
*/
public Grammar(String startSymbol, char terminalMarker) {
this.startSymbol = startSymbol;
this.terminalMarker = terminalMarker;
}//contructor


public abstract void addRule(String m, String v);

public abstract void removeRule(String m, String v);

public abstract List<Object> getTerminals();

public abstract List<Object> getNonTerminals();
}//Grammar
[/HIGHLIGHT]

was ich mich grad aber Frage ... Bisher arbeite ich ja mit Strings als (Non-)Terminalsymbolen. Mal angenommen man könnte später eigenen Klasen dafür einführen, ist dann die gewählte Variante hier mit List<Object> sinnvoll!? Sicherlich muss ich dann beim Auslesen casten, ist aber eigenltich der gängige Weg in dem Fall oder?! Somit schreibe ich den vererbten Klassen nicht vor welche Basis sie für ihre Symbole verwenden.

Wenn ich bei nem ActionListener die Source casten geh ich ja auch implizit davon aus das mir das Framework bei ner Anbindung an JButton nicht nen JTextfield da reinsetzt

 

[hdi]

2 Dinge:

1) hast du nicht (ganz) das gemacht, was ich meinte: abstrakte Klassen = nicht so gut wie Interfaces.
Im Moment egal, aber für später bietet ein Interface leichtere Änderungsmöglichkeiten.

2) Für dein Terminal-Zeugs hab ich eine Idee. Ich hatte davor eine andere (viel bessere)
Idee, konnte sie aber nich realisieren und weiss nicht ob das geht.
Hier würde ich einen Profi bitten, zu helfen (dazu unten mehr).
Erstmal die zweite Idee:

Mach eine List<TerminalObject>, und das ist ein Interface mit einer Methode :

public Object getTerminal();

Mach dir eine Implementierung namens "TerminalString", die das Interface
implementiert und bei der getTerminal einen String rerturned.

Zwar musst du dann noch immer nach String casten, allerdings kannst du jetzt eine
neue Implementierung machen "TerminalWhateverObject", die ein WhatEverObject
bei der getTerminal() returned.

per instanceof kannste prüfen welche Implementierung das ist und entsprechend casten.
ISt kaum besser, aber vllt doch ein wenig leichter abzuändern, und vorallem wieder zurück
zu ändern im Nachhinein.
Aber zugegeben: Nich der Brüller,ich weiss! Also kannst es auch eher nich machen

So, und meine Frage an die Profis:
Eig. wollte ich ihm folgendes vorschlagen:

Eine List<TerminalObject>, das ein Interface ist:

[HIGHLIGHT="Java"]interface TerminalObject<T>{
public <T> getTerminal();
}
[/HIGHLIGHT]

und einzelne Implementierungen könnten jetzt sagen: Es is ein String, oder ein ObjectWhatever usw.
Damit würden jegliche Überprüfungen an der Stelle, wo getTerminal() aufgerufen werden,
wegfallen, weil immer das richtige zurückkommt, und man könnte sich eben ohne Änderungen
neue Implementierungen zusammenschreiben.

Hoffe ist klar, was ich meine?!

Auf jeden Fall geht das so nicht, aber mit Generics und Wildcards etc kenn ich mich
leider noch nicht gut (sagen wir mal so: gar nicht!) aus.

Kann man diese Idee irgendwie verwirklichen??

edit: Hoffe das wird nich als Spam gesehen, aber dafür mach ich nen neuen Thread
auf mit passendem Titel!

 

[diggaa1984]

hm also die Wahl der Implementierung würde ja gar nicht nach aussen hin möglich sein, das wäre nur eine Sache der abgeleiteten Grammatiken. Und da würde ich irgendwo schreiben welche Implementierung verwendet wurde, damit der Nutzer weiss, welchen Cast er ansetzen darf

Ich seh grad keinen grossen Vorteil, oder eine Änderung in der Flexibilität, wenn ich das Interface umsetze, da Terminals in dem Sinne keiner oberen Struktur zugeordnet werden (ausser implizit Object) müssen. Das einzige was da schieflaufen könnte wäre, dass die Grammatiken (ContextFreeGrammarBNF etc.) in eine List<Object> völlig inkonsistente Datentypen reinlegen dürfen. Aber da kommt mein Vergleich mit dem ActionListener, wo ich sage, dass ich als Nutzer auch davon ausgehe, das dort als Source die Komponente drin liegt an die ich den ActionListener binde und ich dementsprechen implizit weiss wohin ich casten muss.

Also ich appelieren an die Vernunft der Grammatiken auch nur einheitliche Datentypen in der Liste abzulegen. Im Moment appeliere ich da nur an meine Vernunft (Studienarbeit) .. aber wer weiss was die Uni mal mit dem Programm noch vorhat.

aso und zu 1. war ja die idee das ich zumindest identische Sachen in die Oberklassen auslagern kann, und da is mitm interface nich mehr viel