Design-Problem Formel-Parser

[Landei]

Ich habe einen Formel-Parser, der relativ unabhängig arbeitet. Er soll jedoch auch Konstanten, die von "außen" geliefert werden, verarbeiten können. Genau diese Verbindung macht Probleme.

Ich benutze eine Klasse ConstToken, die eine Unterklasse von ValueToken ist (die anderen Unterklassen sind Zahlen und Variablen):

public abstract class ValueToken<T> implements Token<T> {
    public abstract T get();
}

public class ConstToken<T> extends ValueToken<T> implements Token<T> {

    private final String name;
    private final ConstProvider<T> provider;
    
    public ConstToken(String name, ConstProvider<T> provider) {
        this.name = name;
        this.provider = provider;
    }
    
    @Override
    public T get() {
        return provider.get(name);
    }
    ...
}

Die Verbindung mit der "Umgebung", die die Konstanten-Werte liefert, geschieht über das Interface ConstProvider:

public interface ConstProvider<T> {
   public T get(String name);
   public boolean exists(String name);
}

Das alles wäre in einer "statischen" Umgebung kein Problem. Ich habe jedoch in Probleme, wenn ich alles initialisiere (weil dann eine Formel über ConstProvider auf eine andere Formel verweisen kann, die noch gar nicht konstruiert wurde), und wenn eine Formel kopiert wird (weil sich dann die Bedeutung dessen, was referenziert wird, teilweise ändert - etwa so, wie wenn man ein Programm verschiebt, das relative Pfadnamen benutzt).

Wie kann ConstToken zu seinen Werten gelangen, ohne sich über ConstProvider zu früh und zu stark an die Umgebung zu koppeln?

Ich habe das dumme Gefühl, dass ich irgend etwas Offensichtliches übersehe. Es doch muss irgendeine Möglichkeit zu einer Art Lazy Loading mit gleichzeitiger Inversion of Control geben...

 

[Marco13]

Hm - für konkretere Tipps müßte ich da jetzt auch erst genauer überlegen (und bezweifle auch, dass ich auf abstraktere oder elegantere Ideen kommen würde, als du). Aber mir stellt sich die Frage, ob das überhaupt immer in der allgemeinsten Form gelöst werden kann: Man könnte da doch etwas bauen, wo zwei ConstToken gegenseitig das sind, was von ihrem ConstProvider zurückgeliefert werden soll (kurz: Eine zirkuläre Anhängigkeit) ....?!

 

[Landei]

Eine unschöne Lösung wäre, den ConstProvider erst "im letzten Moment" mitzugeben (und alle Tests auf Gültigkeit extern zu erledigen):

public class ConstToken<T> extends ValueToken<T> implements Token<T> {
 
    private final String name;
  
    public ConstToken(String name) {
        this.name = name;
    }
    
    public T get(ConstProvider<T> provider) {
        return provider.get(name);
    }
    ...
}

Damit könnte man allerdings nicht mehr ValueToken als Oberklasse verwenden (was bisher die Implementierung des Parsers sehr vereinfacht hat). Oder ich ändere die Signatur von get auch in ValueToken, und muss dann für Zahlen und Variablen einen völlig überflüssigen ConstProvider mitgeben.

Da muss ich nochmal drüber meditieren, kann doch nicht so schwer sein...

 

[ThreadPool]

Wie kann man sich denn solche "Konstanten von außen" vorstellen? Was ist denn das Alles?

 

[Marco13]

Hmnee, ich hätte schon vermutet, dass das den Grundgedanken des ValueToken ziemlich kaputt machen würde. Ich weiß nicht, wie du die Variablen und deren Belegung jetzt gelöst hast, oder wie das Konstruieren der Formel im Moment genau implementiert ist, oder wie die Auswertung genau abläuft (und wie viel oder wenig sie mit der Konstruktion zusammenhängt - u.U. könnte ja JEDES Token eine get-Methode haben, die bei "OperatorTokens" dann eben die Auswertung macht). Aber erstmal könnte man denken, dass während des Konstruierens egal ist, worauf der Const-Provider verweist, weil sein Inhalt ja eigentlich erst bei der Auswertung abgefragt werden muss.... also sowas wie

ConstProvider cp0 = new ConstProvider(null);
ValueToken v0 = new ValueToken(constProviderA);

könnte/sollte ja gehen, und erst bei

Object o = v0.get();

würde dann aus dem ConstProvider eine NullPointerException geflogen kommen. Wenn man aber

ConstProvider cp0 = new ConstProvider(null);
ValueToken v0 = new ValueToken(constProviderA);

[b]cp0.setConstValue(new Object());[/b]

Object o = v0.get();

macht, würde es passen. (Ich gehe davon aus, dass dir das klar ist - es geht nur um die Gründe, warum das eben NICHT funktioniert ... ?)

 

[Landei]

Wie kann man sich denn solche "Konstanten von außen" vorstellen? Was ist denn das Alles?

Glaspreise in einer Preisliste. Nun gibt es sehr viele davon, und der Markt ist sehr dynamisch, deshalb lassen sich Formeln hinterlegen. In den Formeln kann man auf Preise von anderen Produkten oder Eigenschaften des aktuellen Produkts (Dicke, Anzahl Folien u.s.w.) verweisen. Formeln können auch kopiert, nicht nur zwischen Produkten, sondern auch zwischen verschiedenen Kunden u.s.w.

Damit hat man ähnliche Probleme wie in Excel: Wie vermeidet man zyklische Abhängigkeiten, was passiert mit den Referenzen beim Kopieren u.s.w.

 

[Marco13]

Ganz grob und diffus rumgesponnen: Vielleicht wäre irgendeine Art "globaler validation" zu einem bestimmten Zeitpunkt möglich. Für ein Kopieren müßte der ConstProvider entweder eine formal beschreibende, "übertragbare" Identifikation seiner Quelle enthalten, was schon schwierig bis unmöglich sein kann - und ich gehe davon aus, dass es, obwohl die Values ja "Const" sind, nicht reicht, die einmal abzuholen und zu speichern, sobald die Formel, die den ConstProvider enthält, verschoben oder kopiert wird (in diesem Fall könnte man dem ConstToken ja auch direkt den Wert übergeben...)

 

[Landei]

Ich gehe davon aus, dass dir das klar ist - es geht nur um die Gründe, warum das eben NICHT funktioniert ... ?

Im Prinzip mache ich das jetzt so, aber das Problem ist, dass die Zuweisung eines ConstProviders im Konstruktor zu "statisch" ist. Wenn ich z.B. eine Formel (also eine Liste von Tokens) auch für einen anderen Preis verwenden will, brauche ich sie nicht zu kopieren, weil alle Tokens immutable sind - außer wenn ich ConstTokens verwende, die ja dann einen anderen ConstProvider benötigen.

Ich denke, ich muss wirklich in den sauren Apfel beißen, und den Provider erst beim get() mitgeben. ConstToken darf einfach nicht veränderlich sein, das ist das eigentliche Grundproblem, und das ist mir jetzt erst richtig deutlich geworden. Jeder Trick, irgendwie einen Provider dynamisch in ein ConstToken hineinzumogeln (was meine ursprüngliche Idee war), würde mir spätestens beim Kopieren wieder böse auf die Füße fallen.

Danke an alle, ich probiere es so.

[Edit]

Ich sehe gerade Marco's Beitrag. Es würde auf jeden Fall murksig, und ist sehr wahrscheinlich den Aufwand nicht wert. Also kommen wir zur gleichen Schlussfolgerung.

 

[Marco13]

Ich denke, ich muss wirklich in den sauren Apfel beißen, und den Provider erst beim get() mitgeben.

Das hängt ein bißchen mit der Frage zusammen, die ich oben gestellt hatte: Wie werden denn Variablenbelegungen im Moment gelöst? Gibt es Mechanismen, um dieSELBE Formel mit zwei verschiedenen Variablenbelegungen auszuwerten? Worauf das stark vereinfacht rausläuft: In gewisser Hinsicht(!) könnte man das mit dem ConstProvider ja vielleicht "als eine spezielle Form von Variablenbelegung" auffassen... :reflect:

 

[Landei]

Die "Variablen" sind aus Sicht der Formel Konstanten (können und sollen innerhalb der Formel nicht geändert werden). Allerdings können sie sich zwischen zwei Berechnungen ändern, oder eine Formel kann unverändert kopiert werden, wodurch einige Konstanten (nämlich die produktabhängigen Parameter) auch einen anderen Wert annehmen.

Ich denke, ich bin auf dem richtigen Weg, wenn ich die Formel völlig unabhängig vom Rest des Programms mache, und Sachen wie Validierung oder Wertebelegung dem restlichen Programm überlasse. Insbesondere die Konsequenz, dass dadurch Formeln als unveränderliche Objekte implementiert werden können, halte ich für wichtig.

 

[Marco13]

Vielleicht hatte ich das etwas unklar formuliert: Es muss ja irgendeine "Entität" geben, die die Variablenbelegung übernimmt. Die (vereinfacht gesagt) irgendwo den String "fensterDickeInMillimetern" auf den Wert "16.8" abbildet - zurückführbar auf eine Methode ValueProvider#getValueFor(String). Wo ist semantisch, für die Formel, und vielleicht nur aus Sicht der Auswertung, der Unterschied zwischen einer Variablen, deren Wert durch die getValueFor(String)-Methode definiert wird, und und einer Konstanten, d.h. "unveränderlichen Variablen", deren Wert durch eine Methode (Const)ValueProvider#getValueFor(String) definiert wird?
Aber vermutlich habe ich einfach ein viel zu wenig klares Bild (und auch zu wenig theoretisch-allgemeine Ahnung von Parsern und Interpretern) als dass ich das wirklich einschätzen könnte. Wenn du eine gute Lösung hast, ist ja alles in Ordnung