Нууу…
Пазлер 9 — спорно. Можно рассматривать и так, и так. Возможно, JetBrains выбрали менее удобный вариант, но лично я предпочитаю использовать ключевое слово when, если веток больше чем 2.
Пазлер 10 — не баг, однозначно. Из доки следует, что делегат это объект с вот такими методами:
//на чтение
operator fun getValue(thisRef: Any?, property: KProperty<*>): String {
return "$thisRef, thank you for delegating '${property.name}' to me!"
}
//на запись
operator fun setValue(thisRef: Any?, property: KProperty<*>, value: String) {
println("$value has been assigned to '${property.name} in $thisRef.'")
}
У интерфейса kotlin.collections.Map нет таких методов, зато есть соответствующие экстеншн функции в файле MapAccessors.
То есть синтаксис объявления делегата по мапе не магия, которая от нас сокрыта, а вполне традиционный для котлина способ делегирования.
Звучит как «если вы всё сделали правильно и ничего не забыли, компонент гарантированно инициализируется корректно». Вот у меня Spring-конфигурация на Java и, по моему опыту, она вообще ничего не гарантирует. Проект скомпилируется и обосрется через 2 минуты инициализации контейнера, потому что тут не завайрился бин, а тут пропертю забыли подсунуть в файл. Вот это удовольствие автор и имел в виду, когда говорил, что в Spring нет compile time safety.
Ok, сдаюсь, но все же я не видел проект, где это было бы проблемой. Ну не могу я вообразить проект, в котором нужно по пачке пропертей в различные конфиги на каждый чих добавлять, причем не тому, кто создал необходимость в этих пропертях, и все это при отсутствующей документации.
Ну т.е. на него таки вываливают всё это дерьмо сразу.
В зрелом проекте дерьмо неизбежно. Если не Spring, то еще что-нибудь.
Еще как виноват, потому что хеллоуворлды на нем выглядят просто и весело, создавая иллюзию, что вот за тебя крутые дядьки подумали и сделали мегафреймворк на все случаи жизни, а ты просто пишешь 2 строчки кода — и вуаля, у тебя сама собой вырастет шикарная архитектура и все девки будут твои.
В сети достаточно инфы про любую зрелую технологию, зачем взращивать иллюзии если есть возможность ознакомиться с опытом коллег? Опять же, ни про какую технологию авторы и причастные не будут говорить плохо, поэтому их дифирамбы нужно сразу выносить за скобки.
Компилятор таки сможет проверить, что всё заавтовайрится?
Нет, конечно, но при использовании java он позволяет гарантировать, что при наличии всех зависимостей компонент инициализируется корректно.
Ну да, как же, приходит джуниор вася на проект, и вся команда срочно бросается перелопачивать код, чтобы не вывалить на бедного васю всю кучу Spring-фич, которые они используют.
В этом высказывании можно заменить Spring на любую другую не самую простую технологию, смысл особо не изменится. Но, честное слово, я не видел такого не разу. Либо джун Василий не совсем пустоголовый и способен обучаться, либо он не пройдет собеседование и не попадет в проект.
А именно — используем Spring в проекте. Шутка (но с долей правды).
Юзер rraderio выше все правильно сказал. Spring'ом можно инициализировать бины, которые про Spring не знают.
Вообще это здравая мысль, вот только почему-то в поддержку Spring часто звучит такой «аргумент», что он якобы учит молодежь правильной архитектуре.
Тружусь в относительно большом проекте, несколько сотен тысяч строк кода, все на Spring'е, пока все хорошо.
Хочется сказать пару слов в защиту:
Магия — это действительно плохо. Ряд приемов, например, autoscan, лучше использовать с осторожностью или не использовать совсем, тем более что магия часто замедляет инициализацию контекста.
Конфигурировать лучше с помощью Java конфига. Будет вам compile time safety.
Импортировать Java конфиги не легко, а очень легко.
Spring умеет очень много, сложность его велика, но документация очень неплоха, а главное — никто не вываливает всю эту сложность на программиста за раз. Обычно бывает наоборот: нужна какая-то штука, и в попытках найти решение вдруг оказывается, что в Spring'е есть и это!
Подъем контекста Spring'а крупного приложения занимает заметное на глаз время, поэтому в тестах лучше Spring'ом не злоупотреблять. Если же оказывается, что без Spring'а протестировать класс, например, нереально — вы что-то делаете не так.
Spring сам по себе не делает мир лучше. Если бардак в головекоде — начинать надо не со Spring'а.
1) Одно другого не исключает. Нужен тип — пишите.
2) В котлине вы можете объявить функцию в теле метода, вне класса, в классе. И везде такое объявление выглядит одинаково.
3) Объявляйте константы вне класса, если companion object не нравится.
4) "!!" aka оператор "костыли" — не самая изящная часть kotlin, однако, его почти всегда можно избежать.
5) Не со всем понимаю, о чем речь. Конструкторов может быть больше одного.
6) Сначала выглядит странно, но привыкнуть не сложно.
7) Ключевое слово override гораздо строже, чем аннотация (которой может не быть), и это скорее хорошо.
8) Отсутствие наследования по умолчанию — это явный плюс. Я и в java класс не предназначенный для расширения объявлял final, и таковых всегда было большинство. Вообще в большом проекте запрещение всего, что явно не разрешено, чаще сказывается благотворно.
Хочется рассказать впечатлениях от боевого использования.
Проекту, где я тружусь, уже больше 3-х лет. Мы последовательно попробовали Java, Groovy, Scala, Kotlin (последние полтора года).
Итого: победил Kotlin, Java и Groovy остались только в виде legacy, причем Groovy только в тестах (из-за Spock Framework), Scala не прижилась совсем.
Все разработчики смогли относительно безболезненно перейти на Kotlin, а лично я после Groovy и Scala просто сел и начал писать.
Действительно, не все фичи Kotlin удобно использовать из Java, в обратную сторону таких проблем не наблюдается.
Итого: если legacy вас не сдерживает — пробовать можно, нужно и приятно. Если сдерживает — просто немножко подумайте над API ваших компонентов.
Сколько раз на технических интервью на меня косо смотрели, когда говорил, что всякие -XX нужно трогать только от безысходности, если других способов улучшить производительность нет совсем. Теперь есть пруф, что так и надо. )
Учился на инженера по электроснабжению. Государственные экзамены сдал, в вот на диплом мотивации не хватило. Отчислили. Из общежития попросили. Мама тоже намекнула, что не хочет оказывать мне финансовую помощь.
Начал искать работу. Никому не нужен электрик без опыта. И тут вспоминаю, что товарищ звал меня в программисты. А у меня из IT навыков только паскаль да ассемблер, и то в рамках университетской программы… Но я напросился на собеседование.
На собеседовании был предельно честен. Чем-то боссу понравился, и вот, я теперь Java-разработчик — стажер. Два месяца учебных заданий, на третий — первый коммерческий проект и первая зарплата.
Прошло 8 лет, не жалею ни разу.
Иногда побаиваюсь сложных задач.
Боюсь языков программирования со слабой типизацией.
Необходимость мокать final классы, говорит о просветах в дизайне.
Пазлер 9 — спорно. Можно рассматривать и так, и так. Возможно, JetBrains выбрали менее удобный вариант, но лично я предпочитаю использовать ключевое слово when, если веток больше чем 2.
Пазлер 10 — не баг, однозначно. Из доки следует, что делегат это объект с вот такими методами:
У интерфейса kotlin.collections.Map нет таких методов, зато есть соответствующие экстеншн функции в файле MapAccessors.
То есть синтаксис объявления делегата по мапе не магия, которая от нас сокрыта, а вполне традиционный для котлина способ делегирования.
Ok, сдаюсь, но все же я не видел проект, где это было бы проблемой. Ну не могу я вообразить проект, в котором нужно по пачке пропертей в различные конфиги на каждый чих добавлять, причем не тому, кто создал необходимость в этих пропертях, и все это при отсутствующей документации.
В зрелом проекте дерьмо неизбежно. Если не Spring, то еще что-нибудь.
В сети достаточно инфы про любую зрелую технологию, зачем взращивать иллюзии если есть возможность ознакомиться с опытом коллег? Опять же, ни про какую технологию авторы и причастные не будут говорить плохо, поэтому их дифирамбы нужно сразу выносить за скобки.
Нет, конечно, но при использовании java он позволяет гарантировать, что при наличии всех зависимостей компонент инициализируется корректно.
В этом высказывании можно заменить Spring на любую другую не самую простую технологию, смысл особо не изменится. Но, честное слово, я не видел такого не разу. Либо джун Василий не совсем пустоголовый и способен обучаться, либо он не пройдет собеседование и не попадет в проект.
Юзер rraderio выше все правильно сказал. Spring'ом можно инициализировать бины, которые про Spring не знают.
Виноват ли в том Spring?
Хочется сказать пару слов в защиту:
на глазвремя, поэтому в тестах лучше Spring'ом не злоупотреблять. Если же оказывается, что без Spring'а протестировать класс, например, нереально — вы что-то делаете не так.головекоде — начинать надо не со Spring'а.1) Одно другого не исключает. Нужен тип — пишите.
2) В котлине вы можете объявить функцию в теле метода, вне класса, в классе. И везде такое объявление выглядит одинаково.
3) Объявляйте константы вне класса, если companion object не нравится.
4) "!!" aka оператор "костыли" — не самая изящная часть kotlin, однако, его почти всегда можно избежать.
5) Не со всем понимаю, о чем речь. Конструкторов может быть больше одного.
6) Сначала выглядит странно, но привыкнуть не сложно.
7) Ключевое слово override гораздо строже, чем аннотация (которой может не быть), и это скорее хорошо.
8) Отсутствие наследования по умолчанию — это явный плюс. Я и в java класс не предназначенный для расширения объявлял final, и таковых всегда было большинство. Вообще в большом проекте запрещение всего, что явно не разрешено, чаще сказывается благотворно.
Проекту, где я тружусь, уже больше 3-х лет. Мы последовательно попробовали Java, Groovy, Scala, Kotlin (последние полтора года).
Итого: победил Kotlin, Java и Groovy остались только в виде legacy, причем Groovy только в тестах (из-за Spock Framework), Scala не прижилась совсем.
Все разработчики смогли относительно безболезненно перейти на Kotlin, а лично я после Groovy и Scala просто сел и начал писать.
Действительно, не все фичи Kotlin удобно использовать из Java, в обратную сторону таких проблем не наблюдается.
Итого: если legacy вас не сдерживает — пробовать можно, нужно и приятно. Если сдерживает — просто немножко подумайте над API ваших компонентов.
Начал искать работу. Никому не нужен электрик без опыта. И тут вспоминаю, что товарищ звал меня в программисты. А у меня из IT навыков только паскаль да ассемблер, и то в рамках университетской программы… Но я напросился на собеседование.
На собеседовании был предельно честен. Чем-то боссу понравился, и вот, я теперь Java-разработчик — стажер. Два месяца учебных заданий, на третий — первый коммерческий проект и первая зарплата.
Прошло 8 лет, не жалею ни разу.