Heiner KückerOption-Either-Stil in Java |
|
Home Java-Seite Bit Packed Array ASM Improved heterogene Map, HMap Constraint Code Generator JSP WorkFlow PageFlow FlowControl Page Flow Engine Web Flow Engine Control_and_Command JSP_Spreadsheet Code-Generator für Option-Either-Stil in Java verbesserter Comparator Fluent-Interface Code-Generator auf Basis einer Grammatik Visitor mit Multidispatch for-Schleife mit yield-return Kognitions-Maschine semantisches Netz Domain Parser Codegenerator_für hierarchische Datenstrukturen Expression_Engine Formula_Parser Thread Preprocessor State Transition Engine AspectJ Java_Explorer DBF_Library Kalender_Applet SetGetGen BeanSetGet CheckPackage LineNumbers GradDms Excel-Export StringTokenizer JspDoc JspCheck JSP-Schulung Java Server Pages Struts Ascii-Tabellen- Layouter Ascii-Baum- Layouter Ascii-Art-Fluss- Diagramm- Parser AsciiArt AssignmentMatrix Layouter StringSerial Silbentrennung JDBC_Schlüssel- Generierung bidirektional/ unidirektional gelinkte Liste Java_Sitemap Generator XmlBuilder RangeMap StringFormatter VersionSafe XCopy JTextField CommandLine- ParamReader Bitmap-Grafik MultiMarkable- Buffered- InputStream JavaCache JdomUtil CollectionUtil XML Really Pull Parser Log-Filter Remote-Protokoll Sudoku-Generator Delegation statt Mehrfachvererbung Disjunct Interval Set WebCam_Demo Weiterentwicklung_Java Alaska-XBase++-Seite Projekte Philosophien Techniken Konzepte Sudoku Kontakt / Impressum Links SiteMap Letzte Aktualisierung: 27.06.2014 |
Code-Generator für Option-Either-Stil in JavaNachbildung des Scala Option-Either-Stil in Java mit Hilfe eines einfachen Code-Generators. Über diesen Code-Generator gibt es einen Artikel in Java aktuell 2014-03.
Das Ziel dieser Lösung ist die explizite Codierung von Werten / Signalen, die zwischen unterschiedlichen Schichten / Komponenten einer Anwendung ausgetauscht werden. Dabei werden problematische (implizite) Codierungen, wie Magic Numbers (magische Nummern) vermieden. Der transportierte Wert ist magisch auf dem Transportweg, dort wird die abstrakte Oberklasse notiert. An der Erzeuger- und Empfänger-Codestelle ist der Wert explizit. Auf der Erzeuger-Seite wird die jeweilige Variante des Wertes mit typsicherer Nutzlast über generierte Factory-Methoden erzeugt. try { final String sucheErgebnisStr = ...implementierte Suche...; if ( sucheErgebnisStr == null ) { return // Factory-Methode für nichts gefunden SucheResult.notFound(); } return // Factory-Methode für Suche erfolgreich SucheResult.found( sucheErgebnisStr ); } catch ( ValidationException vexc ) { LOGGER.error( "Fehler in Suche " , vexc ); return // Factory-Methode für aufgetretenen Validierungs-Fehler (falsche Such-Parameter) VisitorSucheResult.validationError( vexc ); } catch ( Exception exc ) { LOGGER.error( "Fehler in Suche " , exc ); return // Factory-Methode für aufgetretenen Fehler (Programmfehler, fehlende Datenbankverbindung usw.) VisitorSucheResult.error( exc ); } Auf der Empfänger-Seite muss jede Variante des Wertes explizit behandelt werden, was durch eine zu implementierende abstrakte Klasse erzwungen wird, deren zu implementierenden Methoden die einzelnen Zweige einer if-else-Kaskade bzw eines switch ersetzen, wodurch keine Zweige vergessen werden können und kein (eventuell fehlerbehaftetes) Casten des empfangenen Wertes oder seiner Nutzlast notwendig ist. // gekapseltes Ergebnis der Suche final SucheResult sucheResult = // Ausführen einer Suche SucheService.search( ...Parameter... ); // das gewünschte Ergebnis, welches aus dem Ergebnis der // Suche erzeugt werden soll, ist eine HTML-Seite final String htmlStr = // Instanziieren der Either(Entweder)-Klasse // zum Behandeln des Ergebnisses der Suche sucheResult.new Either Auf der Empfänger-Seite kann nur das korrekte Verzweigen abgesichert werden, weil die Implementierung abstrakter Methoden nur die Methoden-Signatur, aber nicht das Verhalten innerhalb der implementierten Methoden absichern kann.
Ohne den Code-Generator muss die Zusammenarbeit der Schichten / Komponenten durch einen Test abgesichert werden. Test Erzeuger des Wertes Service-Schicht / -Komponente (dies können mehrere sein) +--------+ | Test | +----------------------+ | | ruft mit Parametern | Unit | | Caller |------------------------>| Service / Komponente | nutzt +---------+ | | | |-------->| Mock- | | | empfängt codierten Wert | |<--------| Backend | | Assert |<------------------------| erzeugt Wert | +---------+ | | +----------------------+ +--------+ Test Empfänger des Wertes Empfänger erzeugt ein Ergebnis (Return-Wert) +--------+ | Test | +------------------+ +---------+ | | ruft mit Parametern | Unit | ruft mit Parametern | | | Caller |-------------------->| Empfänger |------------------------>| Mock- | | | | | | Service | | | empfängt Ergebnis | | empfängt codierten Wert | | | Assert |<--------------------| erzeugt Ergebnis |<------------------------| | | | +------------------+ +---------+ +--------+ Empfänger hat Verhalten (ruft weitere Komponente) +-----------+ | Test | +--------------+ +---------+ | | ruft mit Parametern | Unit | ruft mit Parametern | | | Caller |-------------------->| Empfänger |------------------------>| Mock- | | | | | | Service | | | | | empfängt codierten Wert | | | | | reagiert auf |<------------------------| | | | | Wert | +---------+ | | | | | | | ruft weitere | ruft +--------------+ | | | Komponente |----->| aufgerufener | | | | | | Mock | | | +--------------+ +--------------+ | | | | Assert | | | Verhalten |---------------------------------------------------+ +-----------+ je Äquivalenzklasse/Grenzwert des Wertes ist jeweils mindestens ein Test erforderlich Durch diesen Code-Generator können die Interaktions-Tests eingespart werden, Integrations- und System-Tests sind trotzdem erforderlich. Diese Lösung ist leistungsfähiger als Scalas Option-Either-Stil aufgrund der beliebigen Anzahl Varianten mit jeweils typsicherer Nutzlast, nicht nur Some oder None (Option) bzw. Left oder Right (Either). Diese Lösung eignet sich nicht für Komponeneten / Services, die so stark entkoppelt sind, dass sie in unterschiedlichen Programmier-Sprachen geschrieben sein können. Ausnahmen sind Sprachen, die auf der JVM laufen und abstrakte Java-Klassen implementieren können. Warum werden keine Enums benutzt?Enum-Instanzen sind Singletons(Fewtons) und können dadurch keine Member an einer speziellen Instanz transportieren.
Es gibt keinen Mechanismus in Java, um in einer if-else-Kaskade oder einem switch abzusichern, dass alle Enum-Instanzen behandelt werden. LoslegenDer aktuelle Stand der Dokumentation/Anleitung befindet sich im runterladbaren Zip im Verzeichnis doc. Download der Quelldateien OPTION_EITHER.zip
Installation:Entpacken in Verzeichnis Ihrer Wahl und Import als Eclipse-Projekt Start mit den enthaltenen JUnit4-Tests.
Achtung: Erweiterungen und Fixes stelle ich ohne Historie
und ohne Ankündigung hier bereit. Lizenzbedingungen:
Die Programme, Quelltexte und Dokumentationen können ohne
irgendwelche Bedingungen kostenlos verwendet werden. |