- PVSM.RU - https://www.pvsm.ru -
В прошлой части [1] я рассказывал о подводных камнях Kotlin, в этой я расскажу что их перевешивает.
Меня несколько раз спрашивали, а что же такого в Kotlin, что могло бы сподвигнуть на переход с Java, в чем его фишка? Да, Kotlin привнес Null-safety и большое количество синтакcического сахара, закрыл часть слабых мест Java. Но это не становится поводом для перехода. Что может стать? Новые возможности и новая философия.
Об этом говорится в первую очередь. Это действительно делает код более безопасным. Да, есть проблема при вызове Java. Сводится она к двум вариантам:
Сам ещё не использовал, но, судя по всему, это может сильно изменить подход к многопоточному программированию.
К сожалению, тоже ещё не пробовал. На момент начала моего проекта, это было только в бете, да и с angular не был знаком. Сейчас чешутся руки попробовать — единый модуль с DTO для серверной и клиентской части.
Философия Kotlin — Concise, Safe, Interoperable, Tool-friendly (с оф. сайта и докладов).
Совместимость с Java действительно 100%-ая в обе стороны. Чтобы я ни делал, всё работало отлично.
На Eclipse не пробовал, но в Intellij всё замечательно, и продолжает улучшаться.
На мой прогматичный взгляд — это самое главное. Concise, Interoperable, Tool-friendly — это минимаотные условия выживания языков на JVM, иначе они будут проигрывать Java.
К примеру, локальная переменная — list из строк. В java компилятор знает только о двух вариантах:
List<String> list1;
final List<String> list2;
Второй вариант встречается в единичных случаях. Обычно, это не 8-ая Java, и этот list нужен в анонимном классе.
А вот Kotlin:
val list1: List<String>?
val list2: List<String?>?
val list3: List<String>
val list4: List<String?>
val list5: MutableList<String>?
val list6: MutableList<String?>?
val list7: MutableList<String>
val list8: MutableList<String?>
var list9: List<String>?
var list10: List<String?>?
var list11: List<String>
var list12: List<String?>
var list13: MutableList<String>?
var list14: MutableList<String?>?
var list15: MutableList<String>
var list16: MutableList<String?>
Что это дает? У каждого типа есть свои гарантии и набор разрешенных над ним операций. Так, += null можно вызывать только на var list12: List<String?>, а add(null) — на val list8: MutableList<String?> и var list16: MutableList<String?>.
При каждом объявлении писать полный тип будет накладно. Поэтому есть вывод типов:
val test = Random().nextBoolean()
val list1 = if (test) null else listOf("")
val list2 = if (test) null else listOf(null, "")
val list3 = listOf("")
val list4 = listOf(null, "")
val list5 = if (test) null else mutableListOf("")
val list6 = if (test) null else mutableListOf(null, "")
val list7 = mutableListOf("")
val list8 = mutableListOf(null, "")
var list9 = list2?.filterNotNull()
var list10 = list2
var list11 = list2?.filterNotNull() ?: emptyList()
var list12 = list2 ?: emptyList()
var list13 = list2?.filterNotNull()?.toMutableList()
var list14 = list2?.toMutableList()
var list15 = list2?.filterNotNull()?.toMutableList() ?: mutableListOf()
var list16 = list2?.toMutableList() ?: mutableListOf()
Когда пишешь код, не хочется лишнее поле объявлять как nullable, чтобы позже не писать? и ?:, а большая часть операций приводит к immutable коллекциям. В итоге, в коде объявляются самые узкие состояния, что дает более строгие контракты и снижает сложность программы.
data class Schedule(
val delay: Int,
val delayTimeUnit: TimeUnit = TimeUnit.SECONDS,
val rate: Int? = null,
val rateTimeUnit: TimeUnit = TimeUnit.SECONDS,
val run: () -> Unit
)
fun usage() {
Schedule(1) {
println("Delay for second")
}
Schedule(100, TimeUnit.MILLISECONDS) {
println("Delay for 100 milliseconds")
}
Schedule(1, rate = 1) {
println("Delay for second, repeat every second")
}
}
@Repository interface PayerRepository : CrudRepository<Payer, Int> {
fun findByApprenticeId(id: Int): List<Payer>
}
@Repository interface AttendanceRepository : CrudRepository<LessonAttendance, LessonAttendance.ID> {
fun findByDateBetween(from: Date, to: Date): List<LessonAttendance>
}
fun AttendanceRepository.byMonth(month: Date): List<LessonAttendance> {
val from = month.truncateToMonth()
val to = month.addMonths(1).subtractDays(1)
return findByDateBetween(from, to)
}
//ещё 10 репозиторий
inline fun <reified T, ID: Serializable> CrudRepository<T, ID>.find(id: ID): T {
return findOne(id) ?: throw ObjectNotFound(id, T::class.qualifiedName)
}
fun isJournalBlocked(date: Date, forMonth: Date) = forMonth <= date.subtractMonths(1).subtractDays(10)
//используется ещё в 20 местах
fun Date.subtractMonths(amount: Int): Date = DateUtils.addMonths(this, -amount)
//используется ещё в 8 местах
fun Date.subtractDays(amount: Int): Date = DateUtils.addDays(this, -amount)
Java
public boolean isJournalBlocked(Date date, Date forMonth) {
return date.compareTo(DateUtils.addDays(DateUtils.addMonths(forMonth, -1), -1)) <= 0;
}
Надо было хранить последовательности изменения некоторых параметров, для этого написал интерфейс History для хранения такого параметра и extension SortedMap<Date, out History> для выравнивания содержимого после изменений:
interface History<out T> {
val begin: Date
var end: Date?
fun historyOf(): T
fun containsMonth(date: Date): Boolean {
val month = date.truncateToMonth()
return begin <= month && (end == null || month < end)
}
}
fun <T> SortedMap<Date, out History<T>>.fix() {
removeRepeatedNeighbors()
val navigableMap = TreeMap<Date, History<T>>(this)
values.forEach { it.end = navigableMap.higherEntry(it.begin)?.value?.begin }
}
private fun <T> SortedMap<Date, out History<T>>.removeRepeatedNeighbors() {
var previousHistory: T? = null
for (history in values.toList()) {
if (history.historyOf() == previousHistory) {
remove(history.begin)
} else {
previousHistory = history.historyOf()
}
}
}
//usage:
fun setGroup(from: Date, group: ClassGroup) {
val history = GroupHistory(
this, group, from.truncateToMonth(), null
)
groupsHistory[history.begin] = history
groupsHistory.fix()
this.group = groupsHistory.getValue(groupsHistory.lastKey()).group
}
val apprentices: List<ApprenticeDTO> = apprenticeRepository.findAll()
.map(::ApprenticeDTO)
.sortedWith(compareBy({ it.lastName }, { it.firstName }))
Java
List<ApprenticeDTO> apprentices = StreamSupport.stream(
apprenticeRepository.findAll().spliterator(),
false
).map(ApprenticeDTO::new)
.sorted(Comparator.comparing(ApprenticeDTO::getLastName)
.thenComparing(Comparator.comparing(ApprenticeDTO::getFirstName)))
.collect(Collectors.toList());
val attendances: Map<Pair<Date, Int>, Int> attendances = attendanceRepository
.byMonth(month)
.groupBy { it.date to it.group.id }
.mapValues { it.value.count() }
.toMap()
Java
Map<Pair<Date, Integer>, Integer> attendances = attendanceRepository
.byMonth(month)
.stream()
.collect(Collectors.groupingBy((it) -> new Pair<>(it.getDate(), it.getGroup().getId())))
.entrySet()
.stream()
.map(entry -> new Pair<>(entry.getKey(), entry.getValue().size()))
.collect(Collectors.toMap(Pair::getFirst, Pair::getSecond));
Есть filterNot (чаще можно использовать method reference), отдельные first и firstOrNull и т.д… А если чего-то не хватает — дописываешь свой extension (я, к примеру, дописывал sum для листа BigDecimal).
При работе с jsf это просто спасение. Jsf часто дергает одно и то же поле (а я за ним в базу хожу), а в случае таблицы с сортировкой, ожидает, что вернется ровно тот же объект, что и в прошлый раз. А главное, lazy очень легко убрать/вставить.
fun rentForGroup(month: Date, group: ClassGroup): Int {
val hall = group.hall
val hallRent = hall.rent(month)
return when (hallRent) {
is Monthly -> hallRent.priceForMonth() / hall.groups(month).size
is PercentOfRevenue -> hallRent.priceForMonth(creditForGroup(month, group))
is Hourly -> hallRent.priceForLessons(group.monthLessons(month))
}
}
Java
public int rentForGroup(Date month, ClassGroup group) {
Hall hall = group.getHall();
Rent hallRent = hall.rent(month);
if (hallRent instanceof Monthly) {
return ((Monthly) hallRent).priceForMonth() / hall.groups(month).size();
} else if (hallRent instanceof PercentOfRevenue) {
return ((PercentOfRevenue) hallRent).priceForMonth(creditForGroup(month, group));
} else if (hallRent instanceof Hourly) {
return ((Hourly) hallRent).priceForLessons(group.monthLessons(month));
} else {
throw new UnsupportedOperationException();
}
}
inline fun <reified E : Throwable> assertFail(expression: () -> Unit) {
try {
expression()
Assert.fail("expression must fail with ${E::class.qualifiedName}")
} catch (e: Throwable) {
if (e !is E) {
throw e
}
}
}
@Test fun greenTest() {
assertFail<ArrayIndexOutOfBoundsException> {
arrayOf(1, 2)[3]
}
}
Разница небольшая, но шансов ошибиться намного меньше, а ещё можно из инета копипастить без головной боли.
val email = """^([_A-Za-z0-9-+]+(.[_A-Za-z0-9-]+)*@[A-Za-z0-9-]+(.[A-Za-z0-9]+)*(.[A-Za-z]{2,}))?$"""
Java
String email = "^([_A-Za-z0-9-+]+(\.[_A-Za-z0-9-]+)*@[A-Za-z0-9-]+(\.[A-Za-z0-9]+)*(\.[A-Za-z]{2,}))?$"
Кроме того, очень приятные шаблоны [14].
У меня только один проект на Kotlin, не считая мелких поделок. Так что могу с уверенностью сказать одно: Kotlin, Spring и элементы DDD отлично друг друга поддерживают. Если писать на Kotlin как на Java, почувствуется только синтаксический сахар (что уже приятно), но если отказаться от классических бинов, в которые кто угодно может что угодно вставить (а значит, практически нет ограничений на состояния), то Kotlin расцветет.
Автор: Нефедьев Георгий
Источник [15]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/kotlin/263206
Ссылки в тексте:
[1] прошлой части: https://habrahabr.ru/post/331280/
[2] 1. Null safety: https://kotlinlang.org/docs/reference/null-safety.html
[3] 2. Корутины: https://kotlinlang.ru/docs/reference/coroutines.html
[4] 3. Компиляция в JavaScript: https://kotlinlang.org/docs/tutorials/javascript/kotlin-to-javascript/kotlin-to-javascript.html
[5] data class: https://kotlinlang.org/docs/reference/data-classes.html
[6] параметры по умолчанию: https://kotlinlang.org/docs/reference/functions.html#default-arguments
[7] голосовании: https://blog.jetbrains.com/kotlin/2017/06/kotlin-future-features-survey-results/#more-5025
[8] Extensions.: https://kotlinlang.org/docs/reference/extensions.html
[9] Lazy: https://kotlinlang.org/docs/reference/delegated-properties.html#lazy
[10] Smart cast: https://kotlinlang.org/docs/reference/typecasts.html#smart-casts
[11] sealed class: https://kotlinlang.org/docs/reference/sealed-classes.html
[12] Inline functions: https://kotlinlang.org/docs/reference/inline-functions.html
[13] String literals.: https://kotlinlang.org/docs/reference/basic-types.html#string-literals
[14] шаблоны: https://kotlinlang.org/docs/reference/basic-types.html#string-templates
[15] Источник: https://habrahabr.ru/post/337002/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.