Einführung in Scala im Vergleich mit Java

  • 5,235 views
Uploaded on

Eine kleine Einführung in Scala mit einem Hauptschwerpunkt auf den Vergleich mit Java. …

Eine kleine Einführung in Scala mit einem Hauptschwerpunkt auf den Vergleich mit Java.
Innerhalb der Präsentation werden viele Codefragmente von Java mit analogen Fragmenten in Scala verglichen.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,235
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • in Scala vorstellen, dass beides gleich ist. nur sehr umständlich altes beispiel vom auto:
  • Demo in Eclipse: Große Vorteile: ist private, sieht aber aus, wie ein public, code musste nicht neu gemacht werden
  • methoden können auch vorgegriffen werden, da nicht als teil des konstruktors erkannt
  • alle überladenen konstruktoren müssen (!) auf den default verweisen, der im klassenname deklariert ist.

Transcript

  • 1. Sven Naumann, Marcel Rehfeld © Sven Naumann, Marcel Rehfeld
  • 2. Lernziele
    • Kennenlernen der Programmiersprache Scala
    • Grundlegende Syntax verstehen
    • Erkennen von Unterschieden zu Java
    © Sven Naumann, Marcel Rehfeld
  • 3. Gliederung
    • Einleitung
    • Geschichte
    • Scala im Vergleich zu Java
    • Vorteile und Nachteile
    • Werkzeuge
    • Einsatzgebiete
    • Ausblick
    © Sven Naumann, Marcel Rehfeld
  • 4. 1. Einleitung
    • Scala
    • Scala [skah-lah]
    • Skalierbar?
    • Gemischte Konzepte
      • objekt-orientiert
      • funktional
    • Leicht zu verstehen
    • Einfache Integration
    sc alable la nguage © Sven Naumann, Marcel Rehfeld
  • 5. 2. Geschichte
    • Entwickelt von Martin Odersky
    • Wichtige Jahre:
      • 1995: Philip Wadler -> Pizza
      • 1999: Funnel
        • „ Minimalism is great for language designers but not for users.“
      • 2001: Start der Entwicklung von Scala
      • 2003: Erstes Release
      • 2006: Scala v 2.0
    © Sven Naumann, Marcel Rehfeld
  • 6. Scala im Vergleich zu Java vs. © Sven Naumann, Marcel Rehfeld
  • 7. 3. Scala im Vergleich zu Java
    • Einführung
    • OOP
    • Methoden
    • Pattern Matching & Exceptions
    • Traits
    • Interoperabilität
    © Sven Naumann, Marcel Rehfeld
  • 8. Vereinbarung
    • Globale Code-Kennzeichnung:
    System.out.println(“Ich bin Java-Code.”) println(“Ich bin Scala-Code.”) © Sven Naumann, Marcel Rehfeld
  • 9. Einführung © Sven Naumann, Marcel Rehfeld
  • 10. HelloWorld.scala
    • extends Application
      • sehr einfach
      • „ Magic“
    object Main extends Application { println("Hello TIT07AIN :-)") } © Sven Naumann, Marcel Rehfeld
  • 11. Beispiel - main Methode
    • object definiert ein Singleton
    • Modifier static existiert nicht
    • Methoden werden implizit als Public definiert
    • Keine Semikolons
    object Main { def main(args:Array[String]):Unit = { println(args(0)) } } © Sven Naumann, Marcel Rehfeld
  • 12. Beispiel - main Methode (2)
    • Explizite Definition von Variablen
      • variable:Type
      • var myInterger:Int
      • var str:String = "Sven Naumann"
    • Implizite Definition von Variablen
      • var name = „Sven Naumann“
    • Array ist eine echte Klasse
    public static void main(String[] args) { def main(args:Array[String]):Unit = { © Sven Naumann, Marcel Rehfeld
  • 13. Iteration
    • for -Schleife
    • 0 ist ein Objekt
      • mit Methode until
      • definiert ein Objekt der Klasse Range
    for (i:Int <- 0 until args.length) { println(args(i)) } for (int i = 0; i < args.length; i++) { System.out.println(args[i]); } val range:Range = 0.until(args.length) for (i <- range) { © Sven Naumann, Marcel Rehfeld
  • 14. Iteration (2)
    • for-each -Schleife
    • Klasse Array verfügt über die Methode foreach
      • Parameter ist ein Funktionsabschluss (Closure)  anonyme Funktion
    args.foreach(a => { println(a) }) for (String a:args) { System.out.println(a); } args.foreach(a => println(a)) © Sven Naumann, Marcel Rehfeld
  • 15. While-Schleife
    • Identische Syntax wie Java
    var i = 0; while (i < 1000000) { ...; i = i+1 } var i = 0; do { ...; i = i+1 } while (x < 10) © Sven Naumann, Marcel Rehfeld
  • 16. Built-in Types
    • Scala Types basieren auf Java Datentypen
    • Scala = Java (mit anderer Syntax)
      •  Scala Bytecode ist auf JVM ausführbar
    scala.Predef.String scala.Int Array[String] java.lang.String Int (Java primitive) String[] © Sven Naumann, Marcel Rehfeld
  • 17. Objektorientierung © Sven Naumann, Marcel Rehfeld
  • 18. Import
    • Mehr Kontrolle und bessere Übersicht
    • Konsistente Wildcard
    import java.awt.*; import java.awt._ import java.awt.Color; import java.awt.Graphics; import java.awt.{Color, Graphics} © Sven Naumann, Marcel Rehfeld
  • 19. Klassen
    • Beispiel:
    • Mehrere Klassen in einer Datei
    • Dateiname unrelevant
    • Vererbung:
    class SomeTestClass { //... } class NewTestClass extends SomeTestClass { //... } © Sven Naumann, Marcel Rehfeld
  • 20. Reihenfolge der Deklarationen
    • Reihenfolge von Methoden egal
    • Reihenfolge der Klassen egal
    class Sum { def summe() = zahlEins()+zahlZwei() def zahlEins() = 1 def zahlZwei() = 2 } class Sportscar extends Auto { ... } abstract class Auto { ... } © Sven Naumann, Marcel Rehfeld
  • 21. Klassen Felder
    • Beispiel:
    • name ist public
    • name = null
    • Kapselung?
    abstract class Car { var name:String = null } © Sven Naumann, Marcel Rehfeld
  • 22. Klassen Felder (2)
    • Zwei Möglichkeiten in Java:
    public class Sportscar { public String name; } public class Sportscar { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } } © Sven Naumann, Marcel Rehfeld
  • 23. Klassen Felder (3)
    • Beispiel:
    • Was ist, wenn name nicht public sein soll?
    • Was ist, wenn name geprüft werden soll?
    abstract class Car{ var name:String = null } © Sven Naumann, Marcel Rehfeld
  • 24. Klassen Felder (4)
    • Beispiel:
    abstract class Car { private var theName:String = null def name = theName def name_=(name:String)={ if (name != &quot;Smart&quot;){ theName = name println(&quot;Changed name to &quot;+name) }else{ println(&quot;This is no car!&quot;) } } } © Sven Naumann, Marcel Rehfeld
  • 25. Klassen Felder (5)
    • Keine Probleme beim Design des Codes
    • Keine Beeinflussung vorhandener Elemente
    • Sieht aus wie public
    • Keine Getter und Setter mehr
    •  Demo
    © Sven Naumann, Marcel Rehfeld
  • 26. Konstruktoren
    • Alle bisher vorgestellten Klassen hatten Konstruktoren
    • Jede Klasse in Scala hat einen Konstruktor
    • Der Body der Klasse ist der Konstruktor
    © Sven Naumann, Marcel Rehfeld
  • 27. Konstruktoren (2)
    • Ausnahme bilden Methodendeklarationen:
      • werden nicht als Teil des Konstruktors erkannt
      • können vorgegriffen werden
    class TestClassCallsMethod { private var number =1 if (number < 3) { lessThree(number) } def lessThree(value:Int) = println(value+” is less than 3”) } var test = new TestClassCallsMethod() © Sven Naumann, Marcel Rehfeld
  • 28. Konstruktoren (3) public class TestClass{ public TestClass(int number) { if (number > 3) { System.out.println(”Enough testing.&quot;); } } public void doSomething() { ... } } TestClass test =new Testclass(4); // “Enough testing.” class TestClass(number:Int) { if (number > 3) { println(”Enough testing.&quot;) } def doSomething() = { ... } } var test = new TestClass(4) // “Enough testing.” © Sven Naumann, Marcel Rehfeld
  • 29. Konstruktoren (4)
    • Wie funktioniert Overloading?
      • Verweis auf Standard-Konstruktor notwendig!
    class Citycar(ps:Int) extends Car { if (ps < 40) { println(&quot;Slow&quot;) } else { println(&quot;Fast&quot;) } def this() = { this(40) println(&quot;set default ps: 40&quot;) } } © Sven Naumann, Marcel Rehfeld
  • 30. Konstruktor Parameter
    • Alle Konstruktor-Parameter sind automatisch private und values.
    • Zugriff innerhalb von Methoden
    • Kein Reassignment
    • Was ist, wenn noch eine Reise gemacht wird?
    class TravelCar(trips:Int) extends Car{ def moreThanFive = trips > 5 } © Sven Naumann, Marcel Rehfeld
  • 31. Konstruktor Parameter (2)
    • var -Modifier macht trips public
    class TravelingTravelCar(var trips:Int) extends Car { def moreThanFive = trips > 5 def madeTrip() = { trips += 1 println(&quot;Made a trip, now &quot;+trips+&quot; trips.&quot;) } } © Sven Naumann, Marcel Rehfeld
  • 32. Konstruktor Parameter (3) public class Complex { private int a, b; public Complex(int a, int b) { this.a = a; this.b = b; } public int getA() { return a; } public void setA(int a) { this.a = a; } public int getB() { return b; } public void setB(int b) { this.b = b; } } final Complex number = new Complex(1,0); number.setB(12); class Complex(var a:Int, var b:Int) val number = new Complex(1, 0) number.b = 12 © Sven Naumann, Marcel Rehfeld
  • 33. Methoden © Sven Naumann, Marcel Rehfeld
  • 34.
    • Modifier - Sichtbarkeit von Methoden
      • kein public Modifier
      • protected Modifier
        • Zugriff nur von Sub-Klassen
        • Java erlaubt auch Zugriff im selben Package
    Methoden package testing.methods class MethodTestClass { protected[testing.methods] def method() = { ... } protected[de.dhbw.mannheim] def method() = { ... } } def method() = { ... } protected def method() = { ... } © Sven Naumann, Marcel Rehfeld
  • 35. Methoden (2)
      • private Modifier
      • Scala ist mächtiger
      • Erlaubt Zugriff im selben Package, aber nicht von Sub-Klassen
      •  Gilt auch für Feld-Variablen
    private def method() = { ... } package testing.methods class MethodTestClass { protected[testing.methods] def method() = { ... } } © Sven Naumann, Marcel Rehfeld
  • 36. Methoden (3)
    • Andere Modifier:
      • final
      • kein abstract  Methode ohne Implementierung wird implizit abstract
      • kein native  stattdessen Annotation
    final def finalMethod():String = &quot;FinalValue&quot; def abstractMethod():String public abstract String abstractMethod(); @native def nativeMethod():String © Sven Naumann, Marcel Rehfeld
  • 37. Methoden (4)
      • synchronized existiert nicht als Modifier
    def syncMethod() = { synchronized { ... } } public synchronized void syncMethod() { ... } © Sven Naumann, Marcel Rehfeld
  • 38. Methoden (5)
    • Implizite Ermittlung des Rückgabetyps
    • return Statement optional
    def giveForename(name:String) = { var tmp = name.split(' ') tmp(0) } giveForename(&quot;Sven Naumann&quot;) def giveForename(name:String):String = { var tmp = name.split(' ') return tmp(0) } © Sven Naumann, Marcel Rehfeld
  • 39. Überschreiben von Methoden
    • Wichtiges Konzept der OOP
    • Beispiel:
    • Ohne override Modifier: “error overriding method drive in class Car of type ()Unit”
    class Car { def drive() = println(&quot;driving 140km/h&quot;) } class SportsCar extends Car { override def drive() = println(&quot;driving 240km/h&quot;) } © Sven Naumann, Marcel Rehfeld
  • 40. Überschreiben von Methoden (2)
    • @Override Annotation ist bei Java optional
    • Bei Scala Modifier (keine Annotation)
    • Zwingend notwendig bei Scala:
      • Gefahr bei Unbekannter API  Override oder Overload ?
      • Mehrfachvererbergung (Traits)  was passiert bei gleichen Methodennamen?
    © Sven Naumann, Marcel Rehfeld
  • 41. Static?
    • static Notation existiert in Scala nicht!
    • object verwendet das Singleton Pattern
    public class TestClass { public static int a = 1; } object TestClass { val a : Int } public class TestClass { private static TestClass instance; public int a ; private TestClass() {} public static synchronized TestClass getInstance() { ... } } © Sven Naumann, Marcel Rehfeld
  • 42. Static? (2)
    •  einfache Verwendung von Singletons
    • Mischen von normalen und „static“ Feldern:
    • Scala Compiler ist in der Lage zu entscheiden, ob die Klasse oder das Object von TestClass gemeint ist
    •  umständlich
    public class TestClass { public static int a = 1; public int b; } object TestClass { val a: Int } class TestClass { val b: Int; } © Sven Naumann, Marcel Rehfeld
  • 43. Pattern Matching, Case Classes & Exceptions © Sven Naumann, Marcel Rehfeld
  • 44. Pattern Matching
    • Java Bsp.:
    • Switch-Case
    • Reiner Ersatz für if/else-Block
    • Unterstützt nur primitive Typen
    • z.B. String nicht möglich  Enum
    • Scala verwirft Switch-Case  Pattern Matching
    public boolean checkPrime(int number) { switch (number) { case 1: return true; case 2: return true; case 3: return true; case 5: return true; case 7: return true; default: return false; } } © Sven Naumann, Marcel Rehfeld
  • 45. Pattern Matching (2)
    • Syntax
    • Erstes Match gewinnt
    • Kein return notwendig
    • Wildcard als Default-Statement
    • Scala kann noch mehr  Demo
    def matchTest(x: Int): String = x match { case 1 => &quot;one&quot; case 2 => &quot;two&quot; case _ => &quot;many&quot; } println(matchTest(2)) // “two” © Sven Naumann, Marcel Rehfeld
  • 46. Pattern Matching (3)
    • Für alle Typen möglich
    • case 1 prüft auf Integer 1
    • case 2 prüft auf String
    • case 3 prüft auf Typ
    • case 4 Wildcard
    def matchTest2(x: Any): Any = x match { case 1 => &quot;one&quot; case &quot;two&quot; => 2 case y: Int => ”Integer” case _ => “null” } println(matchTest2(&quot;two&quot;)) // 2 © Sven Naumann, Marcel Rehfeld
  • 47. Case Classes © Sven Naumann, Marcel Rehfeld
  • 48. Case Classes
    • Sind reguläre Klassen
    • Exportieren die Parameter der Konstruktoren
    • Sind gut für das Pattern Matching
    • Helfen beim Zerlegen von Datenstrukturen
    • Bieten Möglichkeiten für Hilfsklassen
    • Können nicht von Case Classes erben
    • Werden abstrakt, wenn Implementierung abstrakter Methoden nicht erfolgt
    © Sven Naumann, Marcel Rehfeld
  • 49. Case Classes (2)
    • Beispiel:
    case class Number(value:Int) def checkPrime(n:Number) = n match { case Number(1) => true case Number(2) => true case Number(3) => true case Number(5) => true case Number(7) => true case Number(_) => false } println(checkPrime(Number(5))) // true println(checkPrime(Number(12))) // false © Sven Naumann, Marcel Rehfeld
  • 50. Case Classes (3) © Sven Naumann, Marcel Rehfeld
  • 51. Case Classes (4) class Color(val red:Int, val green:Int, val blue:Int) case class Red(r:Int) extends Color(r, 0, 0) case class Green(g:Int) extends Color(0, g, 0) case class Blue(b:Int) extends Color(0, 0, b) def printColor(c:Color) = c match { case Red(v) => println(&quot;Red: &quot; + v) case Green(v) => println(&quot;Green: &quot; + v) case Blue(v) => println(&quot;Blue: &quot; + v) case col:Color => { print(&quot;R: &quot; + col.red + &quot;, &quot;) print(&quot;G: &quot; + col.green + &quot;, &quot;) println(&quot;B: &quot; + col.blue) } case null => println(&quot;Invalid color&quot;) } © Sven Naumann, Marcel Rehfeld
  • 52. Case Classes (5)
    • printColor
      • Prüfung ob Red, Green oder Blue
        • bei Matching -> Property Value v von Instanz
      • Prüfung ob Color
        • bei Matching wird Color ausgegeben
      • invalid Color
    • Multi-line case
    • Matching übernimmt null-Prüfung
    © Sven Naumann, Marcel Rehfeld
  • 53. Exception Handling © Sven Naumann, Marcel Rehfeld
  • 54. Exception Handling
    • Implementierung fast wie bei Java
    • Unchecked Exceptions
    • Checked könnten implementiert werden
    • Catch ist nicht erzwungen
    def doAnythingUntilFive(n:Int) = { if (n < 1 || n > 5) { throw new IllegalArgumentException(”Some Error.&quot;) } //... } © Sven Naumann, Marcel Rehfeld
  • 55. Exception Handling (2)
    • Erinnert stark an Pattern Matching
    • Führt zu einem catch -Block
    • finally analog zu Java
    try{ doAnythingUntilFive(7) } catch { case e:IllegalArgumentException => e.printStackTrace() // ... case e => { println(“Some other exception.”); e.printStackTrace() } } © Sven Naumann, Marcel Rehfeld
  • 56. Traits © Sven Naumann, Marcel Rehfeld
  • 57. Traits
    • Mehrfachvererbung
    • Diamond-Problem
    © Sven Naumann, Marcel Rehfeld
  • 58. Traits (2)
    • Interfaces  schwache Lösung bei Java
      • keine Implementierung erlaubt
    • Traits  ermöglichen Mehrfachvererbung mit Methodenimplementierung
    • Beispiel:
    © Sven Naumann, Marcel Rehfeld
  • 59. Traits (3) abstract class APerson { def sleep() } trait TStudent extends APerson { override def sleep() = { println(&quot;sleeping 8h&quot;) } def learn() = { println(&quot;learing..&quot;) } } trait TWorker extends APerson { override def sleep() = { println(&quot;sleeping 6h&quot;) } def work() = { println(&quot;working..&quot;) } } class CollegeStudent extends TWorker with TStudent { } © Sven Naumann, Marcel Rehfeld
  • 60. Traits (4)
    • Erweitertes Beispiel:
    class CollegeStudent extends TWorker with TStudent with TLateRiser { } © Sven Naumann, Marcel Rehfeld
  • 61. Traits (5)
    • Override Modifier
      • überschreibt Methode der Klasse davor (Reihenfolge ist wichtig)
      • zwingend notwendig  Sicherstellung, dass Methode überschrieben wird, nicht überladen
    • Keine Konstruktor Parameter bei Traits möglich
    © Sven Naumann, Marcel Rehfeld
  • 62. Interoperabilität zwischen Java und Scala © Sven Naumann, Marcel Rehfeld
  • 63. Interoperabilität zwischen Java und Scala
    • Scala Klassen = Java Klassen
      • identischer Bytecode
      • unproblematisch
    class SomeShowClass extends SomeSuperClass{ private var isThisTrue = false def setTrue(b:Boolean){ isThisTrue = b } } public class AnyJavaImpl extends SomeShowClass{ //... some Java Actions } © Sven Naumann, Marcel Rehfeld
  • 64. Interoperabilität zwischen Java und Scala (2)
    • Traits
      • viel mächtiger als Interfaces
      • Scala kann Traits in Interfaces (und Klassen) compilieren
    • Field Variablen – Getter und Setter (Scala)
      • mit @BeanProperty Annotation
      • Java Konventionen werden eingehalten
      •  Demo
    • scala-library.jar
    © Sven Naumann, Marcel Rehfeld
  • 65. Vorteile und Nachteile © Sven Naumann, Marcel Rehfeld
  • 66. 4. Vorteile und Nachteile
    • Vorteile:
      • Skalierbar!
        • einfacher Einstieg für Anfänger
        • viele Möglichkeiten für fortgeschrittene Benutzer
      • Syntax ist weniger wortreich (verbose)  Reduzierung der Codezeilen
      • „ Neue“ Konzepte wie funktionelle Programmierung, Traits, Pattern Matching, ...
    © Sven Naumann, Marcel Rehfeld
  • 67. 4. Vorteile und Nachteile (2)
    • Vorteile:
      • wird konstant weiterentwickelt
        • Current Stable Release 2.7.7 (28. Okober 2009)
        • Release Candidate 2.8.0.RC1 (14. April 2010)
      • Portabilität  funktioniert auch auf JVM
    © Sven Naumann, Marcel Rehfeld
  • 68. 4. Vorteile und Nachteile (3)
    • Nachteile:
      • teilweise mangelnde Dokumentation
      • Gefahr, dass objektorientierte Ansätze außer Acht gelassen werden
      • (noch) mangelnde IDE Unterstützung
        • Refactoring funktioniert schlecht
        • Pakete werden nicht gefunden
        • ...
    © Sven Naumann, Marcel Rehfeld
  • 69. Werkzeuge © Sven Naumann, Marcel Rehfeld
  • 70. 5. Werkzeuge
    • Unterstützte IDEs
      • Eclipse
      • NetBeans
      • IntelliJ IDEA
    • Skripte -> Demo
    • Konsole -> Demo
    © Sven Naumann, Marcel Rehfeld
  • 71. Einsatzgebiete und Ausblick © Sven Naumann, Marcel Rehfeld
  • 72. 6. Einsatzgebiete
    • Anwendungsgebiete wie bei Java  Plattformunabhängig
    • Noch kein Einsatz für Enterprise Projekte
      • Schulung Programmier Team  Kosten?
      • Mangelnde IDE Unterstützung
      • Einsatz in kleinen Software Projekten
      • Unabhängige Teilprojekte, da Java kompatibel
    • Twitter Message Queue verwendet Scala anstatt Ruby
    © Sven Naumann, Marcel Rehfeld
  • 73. 7. Ausblick
    • Großes Potential als Java Nachfolger
    • Am Tooling für Scala wird gearbeitet
      • Scala 2.8 bringt IDE-freundlicheren Compiler
      • Langfristige Planung: Qualität der Java IDEs erreichen
    • In Unternehmen sind zunächst gemischte Projekte Java – Scala denkbar
    • TIOBE Programming Community Index
      • Java Platz 2, Scala Platz 27
    © Sven Naumann, Marcel Rehfeld
  • 74. Literatur
    • Odersky, Martin; u.a.: Programming in Scala. 1. Auflage. Mountain View, CA: Aritma Press, 2009. – ISBN 0-9815316-0-1
    • Scala: The Scala Programming Language [online]. Letzte Aktualisierung 26.04.10, http://www.scala-lang.org
    • Spiewak, Daniel: Scala for Java Refugees [online]. Letzte Aktualisierung 24.03.09, http://www.codecommit.com/blog/category/scala
    • TIOBE Software, P rogramming Community Index [online]. Letzte Aktualisierung April 2010 http://www.tiobe.com/index.php/content/paperinfo/tpci/
    © Sven Naumann, Marcel Rehfeld