Das Interface

et rechnungsbetrag 01

LF-ET ge­ne­riert aus der Ent­schei­dungs­tabelle ein Interface mit

  • einer 'is-Methode' für jeden Bedingungswert

  • einer 'do-Methode' für jeden Aktionswert

  • einer Trace-Methode, mit der die Ausführung der Regeln protokolliert werden kann

Falls andere als die auto­matisch erzeugten Methoden­namen generiert werden sollen, so kann das indivi­duell für einzelne Bedingungen und Aktionen mit dem Inline-Parameter $$MethodName konfiguriert werden. 
// *** WARNING: DO NOT MODIFY *** This is a generated Java source code!
//
// Generated by LF-ET 2.4.1 (260219a), https://www.lohrfink.de/lfet
// From decision table
// "/src/main/resources/lfet/demo/Rechnungsbetrag.lfet"
// 24.02.2026 11:20
//

// Prolog Standard ---->
// profile LFET.Java.Prolog.Standard.Interface.ini not found
// used LF-ET 2.4.1 (260219a) build in default

package lfet.demo;

import javax.annotation.processing.Generated;

@Generated("LF-ET")
interface Rechnungsbetrag_iFace
{

    // Prolog Standard <----

    /**
     * <b>B01: Bestellwert</b><br>
     * <br>
     * <b>B01/01: &lt; 20,00 - gering</b>
     */
    boolean isBestellwert_Kleiner2000();

    /**
     * <b>B01: Bestellwert</b><br>
     * <br>
     * <b>B01/02: 20,00 - 75,00 - normal</b>
     */
    boolean isBestellwert_20007500();

    /**
     * <b>B02: Rabatt</b><br>
     * <br>
     * <b>B02/01: &gt;0 - Rabatt wurde erfasst</b>
     */
    boolean isRabatt_Groesser0();

    /**
     * <b>B03: Rabattvariante</b><br>
     * <br>
     * <b>B03/01: % - prozentualer Nachlass auf den Bestellwert</b>
     */
    boolean isRabattvariante_ProzentualerNachlassAufDenBestellwert();

    /**
     * <b>B04: Rabatt &lt; Bestellwert</b><br>
     * <br>
     * <b>B04/01: J - Ja</b>
     */
    boolean isRabattKleinerBestellwert();

    /**
     * <b>A01: Rabatt ber&uuml;cksichtigen</b>
     */
    void doRabattBeruecksichtigen();

    /**
     * <b>A02: Porto berechnen</b>
     */
    void doPortoBerechnen();

    /**
     * <b>A03: Rechnungsbetrag</b><br>
     * <br>
     * <b>A03/01: akt. - Rechnungsbetrag muss aktualisiert werden</b>
     */
    void doRechnungsbetrag_Akt();

    /**
     * <b>A03: Rechnungsbetrag</b><br>
     * <br>
     * <b>A03/02: &uuml;bern. - Bestellwert kann als Rechnungsbetrag &uuml;bernommen werden</b>
     */
    void doRechnungsbetrag_Uebern();

    void doTrace(String dtName, String version, int rules, int rule);

    // Epilog Standard ---->
    // profile LFET.Java.Epilog.Standard.Interface.ini not found
    // used LF-ET 2.4.1 (260219a) build in default

}

// Epilog Standard <----

// End of generated Java source code
// Generated by LF-ET 2.4.1 (260219a), https://www.lohrfink.de/lfet

Für jeden Bedingungswert eine is-Methode

…​fast, denn für den letzten Wert einer jeden Bedingung, dem sogenannten 'Sonst-Wert', wird immer ein ELSE-Zweig ge­ne­riert.

Hier als Beispiel die Methoden für Bedingung B01:

interface 01

/**
 * <b>B01: Bestellwert</b><br>
 * <br>
 * <b>B01/01: &lt; 20,00 - gering</b>
 */
boolean isBestellwert_Kleiner2000();

/**
 * <b>B01: Bestellwert</b><br>
 * <br>
 * <b>B01/02: 20,00 - 75,00 - normal</b>
 */
boolean isBestellwert_20007500();

  • Für jeden Bedingungswert wird aus 'is', dem Titel der Bedingung und dem Symbol des Wertes ein eindeutiger Methodenname erzeugt

  • So wird z.B. aus 'Bestellwert < 20,00' der Methodenname isBestellwert_Kleiner2000

  • Automatisch JavaDoc

    • Aus Bedingungstitel, Symbol und Beschreibung des Wertes und aus einem eventuell zum Wert hinterlegten Text wird für jede Methode ein JavaDoc-Kommentar erzeugt

    • d.h. auch die Kommentare in der Software werden bei der Pflege und Wei­ter­ent­wick­lung der Ent­schei­dungs­tabellen auto­ma­tisch aktuell gehalten

  • Für den letzten Bedingungswert 'Bestell­wert > 75,00' wurde keine Methode ge­ne­riert, weil es sich hier um den sogenannten 'Sonst-Wert', handelt, für den immer ein ELSE-Zweig ge­ne­riert wird

Für jeden Aktionswert eine do-Methode

et rechnungsbetrag 01

Hier zum Beispiel die gene­rier­ten Methoden für die Aktion A03:

/**
 * <b>A03: Rechnungsbetrag</b><br>
 * <br>
 * <b>A03/01: akt. - Rechnungsbetrag muss aktualisiert werden</b>
 */
void doRechnungsbetrag_Akt();

/**
 * <b>A03: Rechnungsbetrag</b><br>
 * <br>
 * <b>A03/02: &uuml;bern. - Bestellwert kann als Rechnungsbetrag &uuml;bernommen werden</b>
 */
void doRechnungsbetrag_Uebern();

  • für jeden Aktionswert wird aus 'do', dem Titel der Aktion und dem Symbol des Aktionswertes ein eindeutiger Methodenname erzeugt

  • unabhängig davon, wie oft die Methode in den Regeln verwendet wird, sie muss nur einmal implementiert werden, den "Einbau" in das Regel­modul übernimmt der Generator

    • A03/01 wird in 6 Regeln (d.h. in 6 Programmzweigen) verwendet

    • A03/02 wird in 1 Regel verwendet

Und eine Trace-Methode

Sie wird im Regel­modul in jeder Regel VOR Ausführung der ersten Aktion aufgerufen.

void doTrace(String dtName, String version, int rules, int rule);

Hinweise

  • Solange an der Ent­schei­dungs­tabelle nur Regeln verändert werden

    • bleibt das Interface - und bleiben damit auch alle Imple­men­tie­run­gen des Inter­faces - gültig

    • kann einfach neu ge­ne­riert werden, betroffen von diesen Änderungen ist nur das Regel­modul, dieses wird auto­matisch komplett neu berechnet und ge­ne­riert

  • Nur wenn in der Ent­schei­dungs­tabelle auch Bedingungen oder Aktionen geändert werden, dann ist auch das Interface betroffen, aber es sind nur gezielte Nachjustierungen einzelner Methoden notwendig

    • Wegfall von Werten: Methoden müssen entfernt werden

    • Geänderte Werte: Methoden müssen angepasst werden

    • Neue Werte: Methoden müssen einmalig implementiert werden

  • In der Regel bieten moderne Ent­wick­lungs­um­ge­bungen zur Unterstützung dieser Nachjustierungen leistungsstarke Funktionen an