Scalaz Einführung für Java Programmierer Bernhard Huemer IRIAN

Transkript

1 Scalaz Einführung für Java Programmierer Bernhard Huemer

2

3 Agenda Keine Einführung in Scala Keine Einführung in Scalaz ("Haskell für Scala") Motivation Transaktionen mit Monads Type classes bzw. Ad-hoc polymorphismus ev. Arbeiten mit der Datenbank ohne* Seiteneffekte ev. Dependency Injection Funktionale APIs gestalten * Fast ohne

4 Referential transparency "An expression is said to be referentially transparent if it can be replaced with its value without changing the behavior of a program." (d.h. keine Seiteneffekte) def square(i: Int) = i * i // Bad! Referenziert auch etwas anderes als Parameter def now() = System.currentTimeMillis() Keine Reassignment von Variablen Keine Setter, keine Mutations Keine Exceptions Keine Konsolenein-/ausgabe Keine Netzwerkkommunikation...

5 Exceptions als Beispiel def f(): Int = { val y = g() try { y + y catch { case e: Exception => 1337 def f(): Int = { try { g() + g() catch { case e: Exception => 1337 def g(): Int = { throw new Exception("No!"); Checked vs. unchecked exceptions (etwas) irrelevant Compiler versichert, dass Seiteneffekte behandelt werden Besser: Sie treten gar nicht erst auf Viel zu triviales Beispiel, ich weiß!

6 Exceptions als Beispiel (2) class Cache (cacheloader: CacheLoader) { def get(key: Key): Value = { //... trait CacheLoader { def load(key: Key): Value // throws Exception! class Cache (cacheloader: CacheLoader) { def preload() { //... def get(key: Key): Value = { //... Refactoring mit oder ohne Seiteneffekte? Exceptions bei preload: Falsch/teilw. initialisierter Cache, fehlendes Exception-Handling*, etc.? Exceptions bei get: Mühsam * z.b: Applikation startet nicht mehr, weil unbenützter Cache Key nicht geladen werden kann, andere Initialisierungen werden nicht eingeleitet, etc. - Autor von Cache hat keinen Einfluss darauf!

7 Call Stack Abhängigkeit Es treten immer dann Probleme auf, wenn wir den Call Stack irgendwie ändern. Multi-threaded Umgebungen Web Services RMI oder sonstiges Remoting generell jegl. Netzwerkkommunikation...

8 "Do or do not. There is no scala.util.try[a]." - Yoda

9 scala.util.try[a] import scala.util.{try, Success, Failure def divide: Try[Int] = for { dividend <- Try(Console.readLine("Dividend:\n").toInt) divisor <- Try(Console.readLine("Divisor:\n").toInt) yield (dividend / divisor) val result: Try[Int] = /*.. */ val resultint = if (result.issuccess) { result.get else { 0 val resultint = result.getorelse(0) val resultint: Try[Int] = result.recover { case e: Exception => 0 Nicht einfach nur ein Wrapper um Exceptions Macht aus einer partiellen Funktion eine totale (d.h. gut!)

10 "... the meaning of RT expressions does not depend on context and may be reasoned about locally, while the meaning of non-rt expressions is context dependent and requires more global reasoning." (FPiS)

11 Typsystem = light-weight proof-system I was eventually persuaded of the need to design programming notations so as to 1. maximise the number of errors which cannot be made, 2. or if made, can be reliably detected at compile time. - Tony Hoare (ACM Turing Award Lecture) Typsystem kann viel mehr beweisen als "x has method f" Compile time = Build time, d.h. Unit Tests sind gut, aber nicht gut genug

12

13 Transaktionen - public void updatesomething() { /*... public List<SomeType> querysomething() { /*... */ Offene vergessen? Richtige Transaktion? Implizite Beziehung zwischen Transaktion und EntityManager Kopplung mit Transaktionsattributen (Propagation, Isolation, etc.), retry?

14 Transaktionen - BMT/Templates public void updatesomething(entitymanagerfactory emf) { transactiontemplate.execute(emf, new TransactionCallbackWithoutResult() { protected void dointransaction(entitymanager em) { updateoperation1(em); updateoperation2(em); ); Wiederverwendung in anderer Transaktion? Offene/richtige Transaktion? (teilweise..) EntityManager (o.ä.) müssen durchgereicht werden

15 Alternative: Transaktions Monad Monad = Abstraktion zur sequentiellen Ausführung von einzelnen Schritten in einem bestimmten Kontext (informell) trait Tx[+A] { // Um die Transaktion "auszuführen" und den Inhalt zu bekommen def run(em: EntityManager): A object Tx { // DSL für Transaktionen (konvertiert Funktion in Tx[A]) def transactional[a](body: EntityManager => A) = new Tx[A] { override def run(em: EntityManager) = body(em) Das ist noch kein Monad, nicht einmal informell. Ich habe unser Reiseziel nur vorweggenommen.

16 Tx[A]-"Hello World" def findallproductids() /* : Tx[List[Int]] */ = transactional { em /* : EntityManager */ => //... def findemployee(employeeid: String) = transactional { em => /*... */ So einfach wie mit Annotations - type inference :) Erstmal vollkommen ohne Abhängigkeiten/Seiteneffekte* Unmöglich falschen EntityManager zu verwenden** * Für Skeptiker unter uns: Wie etwas sinnvolles programmieren ohne Seiteneffekte? ** Tony Hoar wäre stolz auf uns!

17 Tx<A> mit Java 8 Tx<A> = Keine Proxies, keine Konfiguration, keine sonstige "Magie", eigentlich nur ein TransactionCallback<T> mit public interface Tx<T> { public T run(entitymanager em); // Nicht wirklich hilfreich, Return Type sparen wir uns nicht public static <T> Tx<T> transactional( Function<EntityManager, T> body) { return body::apply; public Tx<List<Integer>> findproductids(string searchcrit) { return transactional(em -> /*... */); public Tx<Employee> findemployee(string employeeid) { return em -> /*... */;

18 Tx[A] Ausführung def run[a](emf: EntityManagerFactory, tx: Tx[A]): A = { val em = emf.createentitymanager try { em.gettransaction.begin() val result = tx.run(em) em.gettransaction.commit() result finally { // Rollback (eventuell) und clean-up Fazit bisher: Lediglich BMTs aufgesplittet? Interpretieren des Monads verursacht Seiteneffekte Andere Form der Abstrahierung - eine Beschreibung, viele Möglichkeiten diese zu interpretieren

19 Compiler kennt jetzt Transaktionsklammern // Oh! Wir vergessen, sozusagen def findemployeename(employeeid: String) = findemployee(employeeid).name // Wäre zwar nicht so schlimm.. // ERROR: // value name is not a member of...tx[...employee] // Wir sind aber auch vergesslich! def findmanagerforemployee(employeeid: String) = // Lazy loading kann hier aber schon zu Problemen führen! findemployee(employeeid).department.manager // findemployee(employeeid).run(em).department.manager // ERROR: // value department is not a member of...tx[...employee] Transaktionskontext benötigt, um Inhalt zu bearbeiten (bzw. eine EntityManager Referenz..)

20 Tx[A] Verarbeitung (noch) unschön def findmanagerforemployee(employeeid: String) = transactional { em => findemployee(employeeid).run(em).department.manager public Tx<Employee> findmanagerforemployee(string employeeid) { return em -> findemployee(employeeid).run(em).getdepartment().getmanager(); Lesbarkeit eher suboptimal, etwas umständlich EntityManager sollten wir nicht durchreichen müssen Gesucht: Funktion mit Signatur Tx[A] => (A => B) => Tx[B]

21 Higher-order function: map trait Tx[+A] { self => // Statt "Tx.this" //.. def map[b](f: A => B) = transactional { em => f(self.body(em)) public interface Tx<T> { //.. default public <U> Tx<U> map(function<t, U> f) { return em -> f.apply(run(em)); Nicht nur bei Collections nützlich Strukturerhaltende Verarbeitung von Elementen

22 Verwendung von map() (1) def findmanagerforemployee(empid: String)/*: Tx[Employee] */ = findemployee(empid) map { employee => employee.department.manager public Tx<Employee> findmanagerforemployee(string empid) { return findemployee(empid).map( employee -> employee.getdepartment().getmanager()); Keine EntityManager, - alles wird sozusagen inferred Erstmals wirklicher Unterschied zu der BMT Lösung

23 Verwendung von map() (2) public Tx<Employee> findmanagerforemployee(string empid) { return findemployee(empid).map(employee::getdepartment).map(department::getmanager); def finddepartmentforemployee(empid: String) = for { employee <- findemployee(empid) yield employee.department.manager For comprehensions lediglich syntactic sugar

24 Verwendung von map (2) def findproductids(searchcrit: String) = transactional { em => /*... */ def findproductnames(productids: List[Int]) = transactional { em => /*... */ def findproductnamesfor(searchcrit: String) = for { productids <- findproductids(searchcriteria) yield findproductnames(productids) // od. einfacher: def findproductnamesfor(searchcrit: String) = findproductids(searchcrit) map findproductnames Kompiliert zwar, liefert aber Tx[Tx[List[String] Wir suchen: T[x] => (A => Tx[B]) => Tx[B]

25 Higher-order function: flatmap trait Tx[+A] { self => //.. def flatmap[b](f: A => Tx[B]) = transactional { em => f(self.run(em)).run(em) public interface Tx<T> { //.. default public <U> Tx<U> flatmap(function<t, Tx<U>> f) { return em -> f.apply(run(em)).run(em); Ergebnis von Tx[A] als Eingabe für Tx[B] Tx[B] ersetzt sozusagen Tx[A], führt es aber auch aus Garantiert die selbe Transaktion Garantiert der selbe EntityManager

26 Vergleich mit Java 7 public Tx<List<String>>> findproductnamesfor(final String crit) { return new Tx<List<String>>>() { public List<String> run(entitymanager em) { List<Integer> productids = findproductids(crit).run(em); // self.run(em) return findproductnames(productids).run(em); // f(..).run(em) ; Schwer zu lesen, aber nach wie vor nachvollziehbar(?) Vergleich mit BMT: Suboperationen für sich verwendbar

27 Verwendung von flatmap def findproductnamesfor(searchcrit: String) = findproductids(searchcrit) flatmap { productids => findproductnames(productids) def findproductnamesfor(searchcrit: String) = findproductids(searchcrit) flatmap findproductnames def findproductnamesfor(searchcrit: String) = for { productids <- findproductids(searchcrit) productnames <- findproductnames(productids) yield productnames Zwei Datenbankqueries in der selben Transaktion Wiederum weder EntityManager (o.ä.) - Kontext (hier Tx) wird wiederverwendet

28 Monad Definition für Scalaz implicit val txmonad = new scalaz.monad[tx] { def point[a](a: => A): Tx[A] = transactional { // EntityManger wird nicht benötigt, kann ignoriert werden. _ => a def bind[a, B](fa: Tx[A])(f: A => Tx[B]): Tx[B] = fa flatmap f Essenz: Wir hatten die Implementierung praktisch schon Gibt Zugriff zu nützlichen Monadic Functions Monad Laws beweisen sparen wir uns momentan..

29 Monadic Functions (1) // Um die Signatur zu verdeutlichen: def sequencem[m[_] : Monad, T](ms: List[M[T]]): M[List[T]] = ms.sequence def zipm[m[_] : Monad, T, U](mt: M[T], mu: M[U]): M[(T, U)] = for { t <- mt u <- mu yield (t, u) // In Bezug auf Transaktionen bedeutet das: def jointransactions[t](transactions: List[Tx[T]]): Tx[List[T]] = sequencem(transactions) def jointransactions[t, U](txT: Tx[T], txu: Tx[U]): Tx[(T, U)] = zipm(txt, txu) Kontext gibt dabei die jeweilige Semantik an

30 Monadic Functions (2) def replicatem[m[_] : Monad, A](n: Int, ma: M[A]): M[List[A]] = sequencem(list.fill(n)(ma)) Referential transparency ist ja wieder gegeben

31 Unterschiedliche Datenbanken trait Tx[+A, Tag] { def run: A def map[b](a => B): Tx[B, Tag] = //... def flatmap[b, ArgModule >: Module] (f: A => Tx[B, ArgModule]): Tx[B, Module] = //... object Tx { def transactional[a, Tag](body: EntityManager => A) = //... sealed trait Unit1 sealed trait Unit2 def txunit1[a](body: EntityManager => A) = transactional[a, Unit1](body) def txunit2[a](body: EntityManager => A) = transactional[a, Unit2](body) Tx bezieht sich nun auf bestimmte Datenbank

32 Compiler kennt nun auch Datenbankgrenzen (1) def findemployee(employeeid: String) = txunit1 { /*.. */ def saveemployee(employee: Employee) = txunit2 { /*.. */ // Wir wollen die zwei Operationen kombinieren def findandsaveemployee(employeeid: String) = findemployee(employeeid) flatmap saveemployee // Error:(..) type mismatch; // found :..Tx[Unit,..Unit2] // required:..tx[?],..unit1] // findemployee(employeeid) flatmap saveemployee // ^ Modellierung ist einem selbst überlassen - z.b. common Tx für alle?

33 Compiler kennt nun auch Datenbankgrenzen (2) // Müssen wir über verschachtelte Transaktionen machen def findandsaveemployee(employeeid: String) /*: Tx[Tx[Unit, Unit2], Unit1] */ = findemployee(employeeid) map saveemployee

34 Publikumsfrage: Funktioniert = "db1unit") private EntityManager = "db2unit") private // Employee redundant in zwei Datenbanken speichern public void saveemployee(string employeename) { em1.persist(new Employee(employeeName)); em2.persist(new Employee(employeeName)); def saveemployee(employeename: String) = ( txunit1 { em1 => em1.persist(new Employee(employeeName)), txunit2 { em2 => em2.persist(new Employee(employeeName)) ) Wie sicher ist man bei der Antwort dieser Frage?

35 Demo

36 Fazit Ziel einer jeden API: LEGO(tm) Baukasten Seiteneffekte kann man sehr gut einschränken Deferred Execution / Interpretation, wenn man Seiteneffekte benötigt Der (Scala!) Compiler ist dein Freund!

37 Q&A

38 Buchempfehlungen

39 Buchempfehlungen

40 Danke Bernhard Huemer