Von Java zu Kotlin

Vorwort

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Hallo, hier sind Duncan und Nat. du dieses Vorwort liest, überlegst du wahrscheinlich gerade, ob du ein paar Stunden in den Rest des Buches investieren sollst. Also lass uns gleich zur Sache kommen:

Dieses Buch wird dir nicht beibringen, wie man Computer in Kotlin programmiert.

Wir haben angefangen, ein entsprechendes Buch zu schreiben, aber es wurde schnell klar, dass Kotlin eine große Sprache ist und das Schreiben des Buches länger dauern würde, als wir wollten. Außerdem gibt es bereits einige großartige Bücher in diesem Bereich, und wir wollen nicht mit den Großen konkurrieren.

Wir haben beschlossen, uns das Leben leichter zu machen, indem wir uns darauf konzentrieren, Java-Entwicklern Kotlin beizubringen, und zwar auf der Grundlage eines Workshops namens Refactoring to Kotlin. Dabei wird die Sprache Kotlin durch die Konvertierung von bestehendem Code erlernt und ist (laut unserem Marketingmaterial) für Java-Teams gedacht, die ihr vorhandenes Wissen nutzen wollen, um ihre Kotlin-Einführung zu beschleunigen.

Wir begannen, dieses Buch zu schreiben, aber es wurde schnell klar, dass Kotlin immer noch eine große Sprache ist und wir noch lange daran schreiben würden. Außerdem stellten wir fest, dass motivierte und erfahrene Java-Entwickler das meiste von Kotlin sehr schnell lernen können. Es fühlte sich herablassend an, uns durch Sprachfeatures zu pflügen, die unsere Zielleser wahrscheinlich einfach schätzen und übernehmen werden, sobald sie sie sehen. Also haben wir diese Idee aufgegeben, und das Ergebnis ist:

Dieses Buch wird dir nicht die Sprache Kotlin beibringen.

Warum solltest du es also lesen? Weil wir das Buch geschrieben haben, von dem wir uns wünschten, es wäre schon verfügbar gewesen, als wir Kotlin zum ersten Mal eingeführt haben. Wir sind erfahrene Programmierer, die Java und das Java-Ökosystem gut kennen. Wir hoffen, du bist es auch. Wie wir hast du wahrscheinlich Erfahrung mit einer Reihe anderer Sprachen. Du hast die Grundlagen von Kotlin gelernt und erkannt, dass du deine Systeme anders gestalten musst, um das Beste aus der Sprache herauszuholen. Du hast festgestellt, dass einige Dinge, die in Java umständlich sind, in Kotlin viel einfacher sind und dass einige Funktionen, wie z. B. geprüfte Ausnahmen, überhaupt nicht vorhanden sind. Du willst nicht nur Java-Code in Kotlin-Syntax schreiben.

Vielleicht bist du in einer technischen Führungsposition oder hast dein Team erfolgreich davon überzeugt, Kotlin einzuführen. Vielleicht hast du politisches Kapital investiert, um Kotlin in das Projekt einzubringen. Jetzt musst du sicherstellen, dass der Übergang reibungslos verläuft.

Vielleicht bist du für eine Java-Codebasis verantwortlich und möchtest sicherstellen, dass die Einführung von Kotlin den bestehenden, geschäftskritischen Code nicht destabilisiert. Oder du beginnst ein Kotlin-Projekt von Grund auf, merkst aber, dass dein Design-Instinkt eher zu Java und Objekten als zu Kotlin und Funktionen passt.

Wenn das auf dich zutrifft, so wie auf uns, dann bist du hier genau richtig. Dieses Buch hilft dir, dein Denken und deine Entwürfe so anzupassen, dass du die Vorteile von Kotlin nutzen kannst. Das reicht aber nicht aus, denn du hast bereits bestehenden Code, den du pflegen und verbessern musst. Deshalb zeigen wir dir auch, wie du diesen Code schrittweise und sicher von der Java- zur Kotlin-Syntax und von der Java- zur Kotlin-Denkweise migrierst, indem du die automatischen Refactoring-Werkzeuge der IntelliJ IDE nutzt.

Wie dieses Buch organisiert ist

In diesem Buch geht es um den Übergang von Java zu Kotlin, wobei der Schwerpunkt auf dem Code liegt, aber auch Projekte und Organisationen berührt werden. Jedes Kapitel befasst sich mit einem Aspekt dieses Übergangs, wobei ein Aspekt typischer Java-Projekte betrachtet wird, der auf der Reise verbessert werden kann. Sie sind nach dem Muster Java Way to Kotlin Way benannt, wobei wir empfehlen, den letzteren dem ersteren vorzuziehen. Vielleicht erleichtert Kotlin einen Ansatz, der in Java schwierig war, oder Kotlin rät von einem Ansatz ab, der in Java üblich ist, um das Design in eine Richtung zu lenken, die weniger fehleranfällig, prägnanter und toolfreundlicher ist.

Wir empfehlen dir aber nicht nur , den Kotlin-Weg einzuschlagen. Die Kapitel zeigen auch, wie du die Transformation schaffst: Nicht indem du einfach Java umschreibst, sondern indem du es schrittweise zu Kotlin refaktorisierst, und zwar auf eine Weise, die sicher ist und es uns ermöglicht, eine gemischtsprachige Codebasis zu pflegen.

Wie haben wir die Themen ausgewählt?

Wir begannen mit einer Analyse der Nutzung der jeweiligen Sprachen durch Java- und Kotlin-Entwickler und führten Interviews durch, um Unterschiede und Unklarheiten zu ermitteln. Unterstützt wurde dies durch eine maschinelle Lernanalyse von 33.459 Open-Source-Codebases von Java und Kotlin. Diese identifizierten Kandidaten, die wir in der Form "Ding-zu-anderem-Ding" kennzeichneten, bevor wir sie nach Häufigkeit und Entwickler-Schmerz-Quotient einstuften, um festzustellen, welche es in die Liste schaffen sollten. Schließlich ordneten wir die überlebenden Themen nach...

...das ist nicht gut, wir können dich nicht anlügen.

Die Wahrheit ist, dass wir zunächst Themen ausgewählt haben, über die wir schreiben wollten und die wir für interessant und informativ hielten. Kapitel 15, Gekapselte Sammlungen zu Typaliasen, Kapitel 9, Funktionen mit mehreren Ausdrücken zu Funktionen mit einem Ausdruck und Kapitel 20, E/A ausführen zu Datenübergabe sind typische Beispiele für solche Kapitel. Wir haben auch nach Stellen gesucht, an denen sich Kotlin und Java deutlich unterscheiden, weil wir dort am meisten gelernt haben, wenn wir nach den Gründen für die Unterschiede gefragt haben. Das führte zu Kapiteln wie Kapitel 4, Optional zu Nullable, Kapitel 6, Java zu Kotlin Sammlungen und Kapitel 8, Statische Methoden zu Top-Level-Funktionen.

Während wir diese Kapitel schrieben, tauchten weitere Themen auf, die wir der Liste hinzufügten. Insbesondere als wir die Refactoring-Schritte für ein Kapitel schrieben, stellten wir oft fest, dass wir Änderungen am Code vornahmen, die unserer Meinung nach ein eigenes Kapitel verdient hätten. Kapitel 13, Streams to Iterables to Sequences, Kapitel 10, Functions to Extension Functions, und Kapitel 11, Methods to Properties sind Beispiele dafür.

Das Ergebnis dieses Prozesses ist keineswegs erschöpfend. Wenn du das Inhaltsverzeichnis oder den Index bereits überflogen hast, wirst du feststellen, dass wichtige Themen nicht angesprochen wurden. Nehmen wir zum Beispiel Co-Routinen: Dieser Absatz ist der einzige Verweis auf dieses riesige Thema, denn wir haben festgestellt, dass sie die Art und Weise, wie wir serverseitigen Code schreiben, nicht verändert haben, weshalb wir nicht darüber schreiben wollten. Es gibt noch weitere Themen, die wir gerne behandelt hätten, wenn wir nur Platz und Zeit gehabt hätten: Builder, domänenspezifische Sprachen, Reflection, Dependency-Injection-Frameworks, Transaktionen ... die Liste geht weiter!

Wir hoffen, dass das, worüber wir geschrieben haben, für dich interessant ist. Es ist eher ein Buch über Taktik als über Strategie, das sich auf die kleinen Schlachten konzentriert, die wir von unserem Platz in den Schützengräben aus gewinnen können, und nicht auf das, was durch die Führung ganzer Divisionen erreicht werden könnte. Wenn größere Themen auftauchen, werden wir jedoch versuchen, sie miteinander zu verbinden und die Dinge im letzten Kapitel, Kapitel 23, " Die Reise fortsetzen", zusammenzuführen, in dem wir darüber sprechen, was wir während des Schreibprozesses gelernt haben.

Komplexität

Wie sollten wir die interne Qualität unserer Software beurteilen? Wenn wir davon ausgehen, dass sie das tut, was unsere Kunden wollen oder brauchen, wie können wir dann zwei potenzielle Implementierungen vergleichen oder entscheiden, ob eine Änderung die andere besser oder schlechter macht? Die Antwort, die deine Autoren wählen, ist Komplexität. Wenn alle anderen Dinge gleich sind, bevorzugen wir einfache Designs, die ein vorhersehbares Verhalten ergeben.

Natürlich liegen Einfachheit und Komplexität bis zu einem gewissen Grad im Auge des Betrachters. Eure Autoren haben leicht unterschiedliche persönliche Vorlieben und sind sich daher manchmal nicht einig, ob die eine oder andere Implementierung besser ist. Wenn das der Fall ist, gehen wir im entsprechenden Kapitel auf die Alternativen ein. Wir glauben jedoch beide an die Kraft der funktionalen Programmierung, um die Komplexität unserer Systeme zu reduzieren, vor allem in Kombination mit objektorientierter (OO) Nachrichtenübermittlung.

Java hat sich im Laufe der Jahre in diese Richtung bewegt, Scala ging in Richtung funktionale Programmierung, aber weg von OO. Wir finden, dass Kotlin es uns ermöglicht, funktionale und objektorientierte Programmierung auf eine Art und Weise zu mischen, die die Komplexität reduziert und das Beste aus den normalsterblichen Entwicklern herausholt.

Perfekter Code

Auf sollten wir uns mit der Qualität des Codes befassen. Es ist sehr verlockend, Perfektion anzustreben, wenn man Code in ein Buch schreibt. Wir wissen, dass ihr uns nach dem Code beurteilen werdet, und wie bei vielen Entwicklern hängt ein großer Teil unseres Selbstwertgefühls von der Qualität unserer Arbeit ab.

Gleichzeitig sind wir Ingenieure und keine Künstler. Unsere Aufgabe ist es, Umfang, Zeitplan und Kosten für unsere Kunden auszubalancieren. Niemand außer uns kümmert sich wirklich um die Qualität des Codes, es sei denn, sie beeinträchtigt einen dieser drei höheren Werte.

In unseren Beispielen haben wir also versucht, realistischen Produktionscode zu zeigen. Die Ausgangspunkte sind manchmal nicht so gut, wie wir es gerne hätten; schließlich versuchen wir, Wege zur Verbesserung aufzuzeigen. Oft werden die Dinge durch Refactorings erst schlechter, bevor sie besser werden, also beurteile uns auf keinen Fall nach dem Code in der Mitte eines Kapitels. Unser Ziel ist es, am Ende eines Kapitels einen Code zu haben, der gut genug ist, aber nicht so perfekt, dass man uns vorwerfen könnte, das Geld unserer Kunden zu verschwenden.

Wir haben jedoch die Angewohnheit, kosteneffiziente Änderungen vorzunehmen, um aufzuräumen, selbst wenn wir das Thema, das wir illustrieren wollten, bereits abgedeckt haben, und mehr als einmal haben wir ein Thema erfunden und ein Kapitel geschrieben, nur um den Code in einem Zustand zu belassen, mit dem wir zufrieden sind. Schließlich sind wir sowohl Künstler als auch Ingenieure.

Code Formatierung

Unser Code folgt (nach unserer Interpretation) den Standard-Codierungskonventionen von Java und Kotlin, soweit dies möglich ist.

Die praktische Zeilenlänge für gedruckte Codebeispiele ist viel kürzer als die 120 Zeichen, die wir heutzutage normalerweise in einer IDE verwenden, daher mussten wir die Zeilen häufiger als sonst teilen, damit der Code in die Seitenbreite passt. Unser Seriencode hat vielleicht vier oder fünf Parameter oder Argumente in einer Zeile; in diesem Buch haben wir oft nur einen. Durch die Formatierung der Beispiele für die Seite haben wir den eher vertikalen Stil schätzen gelernt. Wir haben festgestellt, dass Kotlin von Natur aus mehr vertikalen Platz braucht als Java, aber auch die Lesbarkeit von Java wird durch kürzere Zeilen, mehr Umbrüche und eine bessere visuelle Ausrichtung verbessert. Das seitliche Scrollen ist in einer IDE fast genauso lästig wie in einem Buch, und unsere Pairing-Sitzungen werden durch weniger Scrollen und mehr nebeneinander liegende Fenster verbessert. Eine Zeile pro Parameter verbessert auch die Unterschiede zwischen den Code-Versionen erheblich. Wir hoffen, dass du es zumindest nicht als zu mühsam beim Lesen empfindest, und wenn nicht, dann probiere es für deinen eigenen Code aus.

Manchmal werden wir Code ausblenden, der für die Diskussion nicht relevant ist. Eine Zeile, die mit einer Ellipse aus drei Punkten beginnt, zeigt an, dass wir einen Teil des Codes aus Gründen der Klarheit oder Kürze weggelassen haben. Zum Beispiel:

fun Money(amount: String, currency: Currency) =
    Money(BigDecimal(amount), currency)

... and other convenience overloads

In diesem Buch verwendete Konventionen

In diesem Buch werden die folgenden typografischen Konventionen verwendet:

Kursiv

Weist auf neue Begriffe, URLs, E-Mail-Adressen, Dateinamen und Dateierweiterungen hin.

Constant width

Wird für Programmlistings sowie innerhalb von Absätzen verwendet, um auf Programmelemente wie Variablen- oder Funktionsnamen, Datenbanken, Datentypen, Umgebungsvariablen, Anweisungen und Schlüsselwörter hinzuweisen.

Tipp

Dieses Element steht für einen Tipp oder eine Anregung.

Hinweis

Dieses Element steht für einen allgemeinen Hinweis.

Warnung

Dieses Element weist auf eine Warnung oder einen Warnhinweis hin.

Code-Beispiele verwenden

Die meisten Codebeispiele im Buch (die aus den Refactoring-Kapiteln) können online auf GitHub abgerufen werden. Die Referenz steht direkt nach dem Code, so wie hier:

class TableReaderAcceptanceTests {
    @Test
    fun test() {
    }
}

Beispiel 0.1 [table-reader.1:src/test/java/travelator/tablereader/TableReaderAcceptanceTests.kt] (diff)

Wenn du dies auf einem Gerät liest, sollte der Verweis ein Hyperlink zu dieser Version der Datei auf GitHub sein. Auf echtem Papier kannst du so viel klicken, wie du willst, es wird nichts passieren, tut mir leid. Aber wenn du die Beispielnummer, in diesem Fall 0.1, in ein Formular auf der Website des Buches eintippst, werden dir Links angezeigt, die dich an denselben Ort führen.

In Git werden die verschiedenen Codebeispiele (die sich manchmal über mehrere Kapitel erstrecken) in separaten Zweigen entwickelt. Die Schritte sind mit dem Tag table-reader.1 Der GitHub-Link verweist auf den Code mit diesem Tag, so dass du die gezeigte Datei( hiersrc/test/java/travelator/tablereader/TableReaderAcceptanceTests.kt ) und die anderen Dateien des Beispiels in dieser Version sehen kannst. Du kannst auch andere Tags auswählen, um die verschiedenen Versionen zu sehen, und verschiedene Zweige, um verschiedene Beispiele zu sehen. Um schneller zu navigieren, kannst du das Repository klonen, es in IntelliJ öffnen und das Git-Tool-Fenster verwenden, um zwischen Zweigen und Versionen zu wechseln.

Warnung

Die Codebeispiele sind nicht echt! Die Codebasis lässt sich bauen und besteht ihre Tests, aber sie ist fiktiv. Es gibt Stellen, an denen die Beispiele nicht richtig zusammenpassen, und andere, an denen du, wenn du hinter den Vorhang schaust, sehen kannst, wie wir an den Hebeln rütteln. Wir haben versucht, ehrlich zu sein, aber wir liefern lieber!

Wenn du eine technische Frage oder ein Problem mit den Codebeispielen hast, besuche die Website des Buches oder schreibe eine E-Mail an [e-mail].

Dieses Buch soll dir helfen, deine Arbeit zu erledigen. Wenn in diesem Buch Beispielcode angeboten wird, darfst du ihn in deinen Programmen und deiner Dokumentation verwenden. Du musst uns nicht um Erlaubnis fragen, es sei denn, du reproduzierst einen großen Teil des Codes. Wenn du zum Beispiel ein Programm schreibst, das mehrere Teile des Codes aus diesem Buch verwendet, brauchst du keine Erlaubnis. Der Verkauf oder die Verbreitung von Beispielen aus O'Reilly-Büchern erfordert jedoch eine Genehmigung. Die Beantwortung einer Frage mit einem Zitat aus diesem Buch und einem Beispielcode erfordert keine Genehmigung. Wenn du einen großen Teil des Beispielcodes aus diesem Buch in die Dokumentation deines Produkts aufnimmst, ist eineGenehmigung erforderlich.

Wir freuen uns über eine Namensnennung, verlangen sie aber in der Regel nicht. Eine Quellenangabe umfasst normalerweise den Titel, den Autor, den Verlag und die ISBN. Ein Beispiel:"Java to Kotlin " von Duncan McGregor und Nat Pryce (O'Reilly). Copyright 2021 Duncan McGregor und Nat Pryce, 978-1-492-08227-9."

Wenn du der Meinung bist, dass deine Verwendung von Codebeispielen nicht unter die Fair-Use-Regelung oder die oben genannte Erlaubnis fällt, kannst du uns gerne unter [e-mail] kontaktieren .

O'Reilly Online Learning

Hinweis

Seit mehr als 40 Jahren bietet O'Reilly Media Schulungen, Wissen und Einblicke in Technologie und Wirtschaft, um Unternehmen zum Erfolg zu verhelfen.

Unser einzigartiges Netzwerk von Experten und Innovatoren teilt sein Wissen und seine Erfahrung durch Bücher, Artikel, Konferenzen und unsere Online-Lernplattform. Die Online-Lernplattform von O'Reilly bietet dir On-Demand-Zugang zu Live-Trainingskursen, ausführlichen Lernpfaden, interaktiven Programmierumgebungen und einer umfangreichen Text- und Videosammlung von O'Reilly und über 200 anderen Verlagen. Weitere Informationen findest du unter http://oreilly.com.

Wie du uns kontaktierst

Bitte wende dich mit Kommentaren und Fragen zu diesem Buch an den Verlag:

• O'Reilly Media, Inc.
• 1005 Gravenstein Highway Nord
• Sebastopol, CA 95472
• 800-998-9938 (in den Vereinigten Staaten oder Kanada)
• 707-829-0515 (international oder lokal)
• 707-829-0104 (Fax)

Wir haben eine Webseite für dieses Buch, auf der wir Errata, Beispiele und zusätzliche Informationen auflisten. Du kannst diese Seite unter https://oreil.ly/java-to-kotlin aufrufen .

Schreib eine E-Mail an [e-mail], um Kommentare oder technische Fragen zu diesem Buch zu stellen.

Neuigkeiten und Informationen über unsere Bücher und Kurse findest du unter http://www.oreilly.com.

Finde uns auf Facebook: http://facebook.com/oreilly

Folge uns auf Twitter: http://twitter.com/oreillymedia

Schau uns auf YouTube: http://youtube.com/oreillymedia

Danksagungen

Danke an Hadi Hariri, dass er O'Reilly vorgeschlagen hat, ein Buch zu schreiben, und an Zan McQuade, dass er ihm geglaubt hat. Danke an unsere Redakteurin Sarah Grey, die mit den Konsequenzen leben musste, und an Kerin Forsyth und Kate Galloway, die alles in Ordnung gebracht und das Buch tatsächlich veröffentlicht haben.

Viele Freunde und Kollegen und einige nette Fremde haben Entwürfe geprüft, die von früh und unkoordiniert bis hin zu verlockend fast vollständig reichten. Wir bedanken uns bei Yana Afanasyeva, Jack Bolles, David Denton, Bruce Eckel, Dmitry Kandalov, Kevin Peel, James Richardson, Ivan Sanchez, Jordan Stewart, Robert Stoll, Christoph Sturm, Łukasz Wycisk und Daniel Zappold sowie bei unseren technischen Gutachtern Uberto Barbini, James Harmon, Mark Maynard und Augusto Rodriguez. Wir wissen all eure Vorschläge, Ermutigungen und Offenheit sehr zu schätzen.

Extreme Programming hat die Art und Weise, wie wir Software schreiben, revolutioniert - wir alle sind Ward Cunningham und Kent Beck zu Dank verpflichtet. Unser Dank gilt auch Martin Fowler, ohne den dieses Buch vielleicht nicht geschrieben worden wäre. In Großbritannien hat der eXtreme Tuesday Club diese Ideen seit 1999 weiterentwickelt und eine Kabale von Entwicklern angezogen. Wir haben das Glück, mit vielen talentierten Mitgliedern dieser Gruppe zusammenzuarbeiten und von ihnen zu lernen. Wenn du ein Problem hast, wenn dir sonst niemand helfen kann und wenn du sie finden kannst, kannst du sie vielleicht einstellen.

Duncan's Bit

Ich glaube nicht, dass meine Frau jemals verstehen wird, womit ich meinen Lebensunterhalt verdiene, und es ist unwahrscheinlich, dass sie den Rest dieses Buches lesen wird, aber wahrscheinlich wird sie es bis hierher schaffen. Also danke, Jo McGregor, dass du es erträgst, dass ich schreibe, anstatt Zeit mit dir zu verbringen, und dass du über das Schreiben sprichst, wenn ich Zeit mit dir verbringe. Ohne deine Unterstützung und Ermutigung hätte ich es nicht geschafft. Danke auch an unsere beiden wunderbaren Söhne Callum und Alistair, die uns so stolz machen.

Danke an Vickie Kennish, die sich sehr dafür interessiert hat, die Mutter eines Autors zu werden, und sich während unserer COVID-Spaziergänge nach den Fortschritten erkundigt hat. Mein verstorbener Vater John hätte es sicher lockerer gesehen, aber vor seinen Freunden mit dem Buch geprahlt. Nicht vergessen ist auch unsere wunderbare Katze Sweet Pea, die mir während des Schreibens Gesellschaft leistete, aber kurz vor der Fertigstellung des Buches starb.

Die Freundschaft und Unterstützung von Robin Helliwell war während meines gesamten Erwachsenenlebens eine Konstante. Das Gleiche gilt für meine Schwester Lucy Seal und viele andere Familienmitglieder, die zu zahlreich sind, um sie einzeln aufzuzählen. In meinem Berufsleben danke ich neben denjenigen, die mirFeedback gegeben haben, auch Alan Dyke, Richard Care und Gareth Sylvester-Bradley, die mich über die Maßen beeinflusst und unterstützt haben.

Nat's Bit

Als ich meiner Frau Lamaan erzählte, dass ich vorhabe, ein weiteres Buch zu schreiben, war ihre unmittelbare Reaktion nicht etwa Entsetzen. Dafür und für ihre ständige Ermutigung bin ich ihr zu großem Dank verpflichtet.

Hut ab vor meiner Schwester Lois Pryce und meinem Schwager Austin Vince, deren Motorradreisen, Bücher und Filme die Anwendung zur Planung von Überlandreisen inspiriert haben, die im Beispielcode verwendet wird.

Und danke an Oliver und Alex. Jetzt, wo das Buch fertig ist, stehe ich wieder für Beratungen im Bereich Musik und Spieleprogrammierung zur Verfügung.