Swift kotlin что это
H Swift и Kotlin — о самых важных различиях между этими языками в черновиках Перевод
Здравствуйте, коллеги. Заголовок самоочевиден, приглашаем вас ознакомиться с переводом интересной статьи Кшиштофа Турека. Также отметим, что автор подмечает интересные доработки, отличающие Kotlin от Java при разработке под Android. Слово автору:
Вероятно, многие из вас видели следующее сравнение Swift и Kotlin: nilhcem.com/swift-is-like-kotlin. Получилось довольно интересно, правда? Соглашусь, между этими языками много параллелей, но в этой статье хотелось бы обсудить некоторые важные отличия между ними.
Вероятно, многие из вас видели следующее сравнение Swift и Kotlin: nilhcem.com/swift-is-like-kotlin. Получилось довольно интересно, правда? Соглашусь, между этими языками много параллелей, но в этой статье хотелось бы обсудить некоторые важные отличия между ними.
Я занимался разработкой под Android с 2013 года и большую часть времени писал приложения на Java. Некоторое время назад мне выпала возможность также попробовать силы в iOS и Swift. Меня реально впечатлило, насколько удобоваримый код получается на Swift. Если как следует поработать над кодом, то у вас может получиться настоящая поэма.
Спустя примерно семь месяцев, я вернулся к Android. Но стал писать не на Java, а на Kotlin. На конференции Google IO 2017 представитель Google заявил, что Kotlin будет одним из приоритетных языков для Android-разработки. Поэтому я решил его выучить. Достаточно быстро я заметил, что Kotlin и Swift очень похожи. Однако, никогда не соглашусь, что они почти идентичны. Далее я расскажу о некоторых отличиях между ними. Не обо всех, а о тех, что наиболее меня заинтересовали. Рассмотрим несколько примеров.
Структура vs. класс данных или значимые типы в сравнении со ссылочными
Структура и класс данных – это упрощенные версии класса. Они используются и выглядят схоже:
Однако, как понятно из названия, класс данных – это все равно класс. Ссылочный тип. Структура, в свою очередь – значимый тип. «Ну и что»? – могли бы спросить вы. Позвольте объясню на примере.
Создадим класс данных в Kotlin и структуру в Swift, а затем сравним результаты.
Каково будет значение data для foo2 в обоих случаях? Имеем 4 для класса данных в Kotlin и 2 для структуры в Swift.
Результаты отличаются, поскольку при копировании структуры ( var foo2 = foo1 ) создается независимый экземпляр с собственной уникальной копией данных (как здесь), а при копировании ссылки создаются разделяемые экземпляры (как здесь).
Вероятно, при работе с Java вам приходилось иметь дело с паттерном «Резервная копия». Если нет – самое время это исправить. Здесь эта тема рассмотрена подробнее.
Короче говоря, можно изменить состояние или объекта как такового, или того объекта, который его вызывает. Первый вариант кажется естественным, и такой подход действительно очень распространен, а вот второй — нет. Особенно, если вы предоставляете ссылочный тип, но не знаете, изменилось ли состояние объекта. Из-за этого может осложняться поиск багов. Чтобы предотвратить такую проблему, нужно создавать резервную копию изменяемого объекта, когда передаешь его в класс или за пределы класса. Kotlin в таких ситуациях гораздо удобнее Java, но, все равно, из-за невнимательности возможны некоторые проблемы. Рассмотрим упрощенный пример:
Добавляю новую страницу (Page) в список bookPages и использую ее позже
К сожалению, я также изменил и состояние книги. Хотя и не собирался…
Справиться с таким неудобством помогает паттерн резервного копирования. В Kotlin это – пара пустяков.
Все спокойны, всё в порядке 🙂
А что же в Swift? Всё даром! Да, массивы – это структуры, а структуры, как уже упоминалось выше – это значимые типы, поэтому, если написать:
то вы будете работать со скопированным списком страниц.
Итак, перед нами вновь значимый тип. Понимать разницу между значимыми и ссылочными типами очень важно, если не хотите проблем при отладке. Многие «объекты»в Swift – это на самом деле структуры; таковы, например, enum, Int, CGPoint, Array, т.д.
Интерфейс & Протокол & Расширение
Это моя любимая тема!
Для начала сравним интерфейс и протокол. В целом это почти одно и то же.
*Вы заметите, что нельзя добавить непосредственно в протокол реализацию метода, которая должна использоваться по умолчанию. Вот почему я пометил последний пункт звездочкой. Для этой цели нужно создавать расширение. Вот так изящно мы переходим к еще более интересному материалу – расширениям!
Расширения позволяют обогатить имеющийся класс (или структуру) дополнительными функциями, ничего не наследуя от них. Вот так все просто. Согласитесь, это очень мощная возможность.
Для Android-разработчиков это в новинку, вот почему нам так нравится везде это использовать. Не нужно быть семи пядей во лбу, чтобы написать расширение в Kotlin.
Можно создать расширение для свойств:
Как видите, никаких ключевых слов мы здесь не использовали.
В Kotlin также есть ряд готовых расширений, которые также очень круты собой – напр. “orEmpty()” для опциональной строки:
Вот как выглядит это ценное расширение:
Хорошо, а теперь давайте рассмотрим расширения Swift.
но тогда мы увидим:
Опциональное значение в Swift – это обобщенное перечисление с заданным типом, именуемым Wrapped. В данном случае Wrapped – это строка, поэтому расширение должно выглядеть так:
и использоваться так:
Гораздо сложнее, чем вариант Kotlin, верно? Но, к сожалению, здесь есть и другой недостаток. Как мы уже знаем, Optional в Swift – это обобщенное перечисление, поэтому ваше расширение будет применяться ко всем типам. Прямо скажем, не обнадеживает:
Однако, компилятор вас защитит и не скомпилирует этот код. Но, если добавить другие подобные расширения, то в окошке с подсказками все равно воцарится хаос.
Значит ли это, что расширения в Kotlin реализуются лучше, чем в Swift? Я бы сказал, что расширения Swift просто предназначены для других целей. Ну держитесь, Android-разработчики!
Протоколы и расширения созданы для совместного использования. Вы можете создать собственный протокол и написать расширение для класса, чтобы адаптировать его к этому протоколу. Это уже может показаться безумным – но это еще не все! Также существует феномен, именуемый «условное соответствие протоколу». Это означает, что класс или структура может соответствовать протоколу, если выполняются определенные условия.
Допустим, у нас в приложении много точек, где требуется открывать всплывающие уведомления. Мы чтим принцип DRY и не хотим копипастить по всему коду создание уведомления. Такую проблему можно решить при помощи протокола и расширения.
Сначала создаем протокол:
Теперь у всех UIViewController появилась новая возможность:
Комбинации протоколов и расширений пригодятся и при тестировании. Ребята, сколько раз вы пытались протестировать в вашем приложении финальный класс из фреймворка или одиночку?
В Swift это не проблема.
Рассмотрим такую ситуацию и допустим, что у нас есть протокол Swift и расширение на Kotlin. Если сигнатура метода нам известна, то можно создать подходящий протокол с такой же сигнатурой метода, затем написать расширение, где финальный класс или одиночка непосредственно реализуют этот протокол – вуаля! Вместо того, чтобы напрямую обращаться к классу, можно легко протестировать его при помощи вашего протокола. Код стоит тысячи слов, так что попробуйте сами.
При тестировании вы, возможно, соберетесь проверить, вызывает ли ваш метод drawSomethingOnMap метод drawSomething в словаре фреймворка. Это бывает затруднительно даже при помощи Mockito (широко известная библиотека тестов для Android). Однако, с протоколом и расширением код приобретет следующий вид:
Теперь, смотрите, ваш метод drawSomethingOnMap использует протокол, а не класс
Запечатанные классы — это прокачанные перечисления
Напоследок хотелось бы поговорить о перечислениях.
Перечисление в Kotlin ничем не отличается от перечисления в классической Java, поэтому здесь мне нечего добавить. Однако, теперь у нас есть кое-что новое, можно сказать «суперперечисление» — речь о запечатанном классе. Откуда взялся термин «суперперечисление»? Смотрим документацию Kotlin:
“ …В некотором смысле, это расширение классов-перечислений: множество значений для типа enum также ограничивается, но каждая константа enum существует лишь в единственном экземпляре, тогда как подкласс запечатанного класса может иметь много экземпляров, каждый из которых может содержать состояние.”
Круто, могут содержать состояние. Но как же их использовать?
Это запечатанный класс, моделирующий статус заказа. Он немного похож на перечисление, но с одной оговоркой. В Canceled cсодержится причинно-обусловленное состояние. То есть, существует много причин, по которым может быть отменен заказ.
С перечислением так не получится. Как только вариант перечисления создан, изменить его уже нельзя.
А вы заметили еще какие-нибудь отличия? Здесь я использовал еще одну возможность запечатанного класса. Речь об ассоциированных значениях иного типа. Классическое перечисление требует предоставлять ассоциированное значение для всех случаев, и все значения должны относиться к одному и тому же типу.
Естественно, в Swift есть эквивалент запечатанного класса, и называется он… перечисление. Перечисление в Kotlin – просто реликт из Java, в 90% случаев в этом языке используются запечатанные классы. Сложно провести грань между запечатанным классом Kotlin и перечислением Swift. Они просто называются по-разному, и, конечно же, запечатанный класс – это ссылочный тип, а перечисление – значимый. Пожалуйста, поправьте меня, если я в чем-то неправ.
Swift vs. Kotlin. Отличия важны
Вы наверняка видели это сравнение Swift и Kotlin: http://nilhcem.com/swift-is-like-kotlin/. Довольно интересное, правда? Я согласен, что в этих языках много схожего, но в этой статье я обращу внимание на некоторые аспекты, которые их все-таки разнят.
Я занимаюсь Android-разработкой с 2013 и большую часть времени разрабатывал приложения на Java. Недавно же у меня появилась возможность попробовать iOS и Swift. Я был впечатлен тем, что на Swift получается писать очень клевый код. Если вы приложите усилия — ваш код будет похож на поэму.
Через семь месяцев я вернулся к Android. Но вместо Java начал кодить на Kotlin. Google объявил на Google IO 2017, что Kotlin теперь официальный язык для Android. И я решил учить его. Мне не понадобилось много времени, чтобы заметить сходство между Kotlin и Swift. Но я бы не сказал, что они очень похожи. Ниже я покажу отличия между ними. Я не буду описывать все, а только те, которые мне интересны. Рассмотрим примеры.
Структуры vs. Data-классы. Значения и ссылки
Структуры и Data-классы — упрощенные версии классов. Они похожи в использовании, выглядит это так
Но класс по прежнему остается классом. Этот тип передается по ссылке. А вот структура — по значению. «И что?» спросите вы. Я объясню на примере.
Давайте создадим наш data-класс в Kotlin и структуру в Swift, а затем сравним результаты.
Чему равно data для foo2 в обоих случаях? Ответ 4 для data-класса Kotlin и 2 для структуры на Swift.
Результаты отличаются, потому что var foo2 = foo1 в Swift создает копию экземпляра структуры (детальнее тут), а в Kotlin — еще одну ссылку на тот же объект (детальнее тут)
Если вы работаете с Java, вы вероятно знакомы с паттерном Defensive Copy. Если нет — наверстаем упущенное. Здесь вы найдете больше информации по теме.
В общем: существует возможность изменения состояния объекта изнутри или извне. Первый вариант — предпочтительнее и более распространен, а вот второй — нет. Особенно когда вы работаете со ссылочным типом и не ожидаете изменений его состояния. Это может осложнить поиск багов. Для предотвращения этой проблемы, вам следует создавать защищенную копию мутабельного объекта перед тем как передавать его куда-либо. Kotlin гораздо полезнее в таких ситуациях, чем Java, но по неосторожности все еще могут возникать проблемы. Рассмотрим простой пример:
Я объявил pages как MutableList, потому что хочу их менять внутри этого объекта (добавлять, удалять и т.п.). Pages не private, потому что мне нужен доступ к их состоянию извне. Пока все идет нормально.
Теперь у меня есть доступ к текущему состоянию книги:
Я добавляю новую страницу в bookPages:
К сожалению, я также изменил состояние исходной книги. А это совсем не то, чего я хотел.
Мы можем воспользоваться защищенной копией, чтобы избежать этого. Это очень легко в Kotlin.
Теперь у нас все хорошо. 🙂
А что же Swift? Тут все работает из коробки. Да, массивы — это структуры. Структуры передаются по значению, как мы уже упоминали выше, поэтому когда вы пишете:
вы работаете с копией списка страниц.
Таким образом мы имеем дело с передачей данных по значению. Это очень важно для понимания отличий, если вы не хотите испытывать головную боль во время отладки. 🙂 Многие «объекты» являются структурами в Swift, например Int, CGPoint, Array и т.п.
Интерфейсы и Протоколы и Расширения
Это моя любимая тема. 😀
Начнем со сравнения интерфейса и протокола. В принципе, они идентичны.
Кроме того, для протоколов может потребоваться определенный инициализатор (конструктор в Kotlin).
*Обратите внимание, что вы не можете добавить реализацию метода по-умолчанию прямо внутри протокола. Вот почему я добавил звездочку к последнему пункту списка. Вам нужно добавить расширение для этого. И это хороший способ перейти к более интересной части — расширениям!
Расширения позволяют добавлять функционал к существующим классам (или структурам ;)) не наследуя их. Это так просто. Согласитесь, это крутая возможность.
Это что-то новое для Android-разработчиков, поэтому нам нравится пользоваться этим постоянно! Создавать расширения в Kotlin — не запускать ракеты в космос.
Вы можете создавать расширения для свойств:
Как видите, мы не использовали здесь никаких ключевых слов.
В Kotlin есть некоторые предопределенные расширения, которые довольно круты, например «orEmpty()» для опциональных строк:
Это полезное расширение выглядит так:
‘?:’ пытается получить значение из ‘this’ (что является текущим значением нашей строки). Если же там будет null, взамен будет возвращена пустая строка.
Так-с, теперь посмотрим на расширения в Swift.
Определение у них то же, поэтому не буду повторяться как заезженная пластинка.
Если вы будете искать расширение подобное «orEmpty()» — у меня для вас плохие новости. Но можно его добавить, не так ли? Давайте попробуем!
но вот что вы увидите:
Опционал в Swift — это generic-перечисление, с заданным типом Wrapped. В нашем случае Wrapped — это строка, поэтому расширение будет выглядеть так:
Выглядит сложнее, чем Kotlin-аналог, не так ли? И, к сожалению, есть еще и недостаток. Как вы знаете опционал в Swift — generic-перечисление, поэтому ваше расширение будет доступно для всех опциональных типов. Выглядит не очень хорошо:
Однако компилятор защитит вас и не скомпилирует этот код. Но если вы добавите больше таких расширений — ваша автоподсказка будет забита мусором.
Значит Kotlin-расширения удобнее чем в Swift? Я бы сказал, что расширения в Swift предназначены для других целей ;). Android-разработчики, держитесь!
Протоколы и расширения созданы, чтоб работать вместе. Вы можете создать свой протокол и расширение для класса, чтоб соответствовать этому протоколу. Это звучит безумно, но это еще не все! Есть такая вещь, как условное соответствие протоколу. Это означает, что класс/структура может соответствовать протоколу при выполнении определенных условий.
Допустим у нас есть много мест, где необходимо показать всплывающий alert. Нам нравится принцип DRY и мы не хотим копипастить код. Мы можем решить эту проблему используя протокол и расширение.
Сначала создадим протокол:
Затем, расширение с реализацией по-умолчанию:
Так-с, метод presentAlert только создает alert, но ничего не показывает. Нам нужна ссылка на вью-контроллер для этого. Можем ли мы передать его как параметр в этот метод? Не очень хорошая идея. Давайте воспользуемся условием Where!
Что у нас тут? Мы добавили специфическое требование к расширению нашего протокола. Оно предназначено только для UIViewController. Благодаря этому мы можем пользоваться методами UIViewController в методе presentAlert. Это позволяет нам вывести alert на экран.
Теперь у всех UIViewController появилась новая возможность:
Также, комбинация протоколов и расширений очень полезна для тестирования. Ребята, сколько раз вы пытались тестировать Android final-класс в своем приложении? Это не проблема для Swift.
Приглядимся к этой ситуации и предположим, что у нас есть final-класс в Swift. Если мы знаем сигнатуру метода, то можем создать протокол с таким же методом, а затем добавить расширение, реализующее этот протокол, к нашему final-классу, и вуаля! Вместо непосредственного использования этого класса — мы можем использовать протокол и легко тестировать. Пример кода вместо тысячи слов.
В тесте нам нужно проверить вызывается ли метод drawSomething у объекта map при отработке метода drawSomethingOnMap. Это может быть сложно даже с Mockito (хорошо известной тест-библиотекой для Android). Но с протоколом и расширением — это будет выглядеть так:
И теперь ваш метод drawSomethingOnMap использует протокол вместо класса.
Sealed-классы — перечисления на стероидах
Наконец, я хотел бы упомянуть перечисления.
Нет отличий между Java-перечислениями и Kotlin-перечислениями, поэтому тут мне добавить нечего. Но у нас есть кое-что новое взамен, и это «супер-перечисления» — sealed-классы. Откуда взялось понятие «супер-перечисление»? Обратимся к документации Kotlin:
«… Они, в некотором смысле — расширения для enum-классов: набор возможных значений для перечислений также ограничен, но каждая enum-константа существует только в единственном экземпляре, в то время как наследник sealed-класса может иметь множество экземпляров, которые могут хранить состояние.»
Окей, круто, они могут хранить состояние, но как мы можем этим пользоваться?
Это sealed-класс, который является моделью статуса заказа. Очень похоже на то, как мы работаем с перечислениями, но с одной оговоркой. Значение Canceled содержит причину отмены. Причины отмены могут быть разными.
Мы не можем делать так с обычными перечислениями. Если значение перечисления создано — его уже не изменить.
Вы обратили внимание, на другие отличия? Я воспользовался еще одной фишкой sealed-класса. Это — связанные данные разных типов. Классическое перечисления предполагает передачу связанных данных для всех вариантов значений перечисления, и все значения должны быть одного и того же типа.
В Swift есть эквивалент sealed-класса и он называется… перечисление. Перечисление в Kotlin — это просто пережиток Java, и 90% времени вы будете пользоваться sealed-классами. Трудно отличить sealed-класс от перечисления Swift. Они отличаются только названием и, конечно же, sealed-класс передается по ссылке, а перечисление в Swift — по значению. Пожалуйста, поправьте меня, если я не прав.
Мы не прощаемся
Существует еще нюансы влияния управления памятью на способ написания кода. Я знаю, что не охватил все аспекты, и это потому, что я еще учусь. Если вы, ребята, заметили какие-либо другие отличия между этими двумя языками — дайте мне знать. Я всегда открыт к новому!
Kotlin и Swift. Новая эпоха в мобильной разработке?
Когда в Google объявили о том, что они теперь официально будут использовать Kotlin для разработки под Android, я, как и многие другие Android-разработчики, вздохнул с облегчением. Я еще раз зашел на официальный сайт Kotlin, чтобы перепроверить функционал/синтаксис и сравнить его с последней версией Swift, на котором сейчас пишу, и вдруг ощутил это: проходит одна эпоха и начинается новая, по крайней мере в мобильной разработке.
В Kotlin, как и в Swift довольно много синтаксического сахара, который снижает объемы обычной рутины (сравнение синтаксиса тут). Но что меня особенно радует — они оба, прям «из коробки», поддерживают новые парадигмы программирования. Особенно функциональное программирование.
Принципы функционального программирования, конечно, не являются чем-то новым в разработке, даже наоборот. Но теперь, когда есть официальная поддержка «из коробки» в разработке под iOS и Android — стоит пользоваться именно ими.
Когда я только начинал свою карьеру в мобильной разработке, все писали циклы как-то так:
Теперь же все используют функциональный подход, чтобы сделать все то же самое за один вызов, и этот подход намного лучше:
Блоки были представлены Apple для Objective-C в 2010 году (iOS SDK 4.0), чтобы улучшить жизнь разработчиков и соответствовать анонимным классам в Java, которые могут быть использованы как коллбэки:
Пример блока в Objective-C:
Пример анонимного класса в Java:
Лямбда-выражения в Java были представлены в 2014, как часть JDK 8, но к сожалению они не были доступны Android-разработчикам, потому что Android SDK поддерживает только JDK версии 7 (поэтому и есть такие библиотеки, как retrolambda).
Теперь же оба языка полностью поддерживают такой подход: в Swift — «замыкания» (то же самое, что блоки в Objective-C), а у Kotlin есть поддержка «лямбд», которая работает в Android SDK:
Пример замыкания в Swift:
Пример лямбды в Kotlin:
Начиная с Xcode 4, где-то с 2011, Objective-C предоставляет однострочную инициализацию для массивов и словарей:
Пример инициализация в Swift:
В JDK доступна только статическая инициализация, но нет способа инициализировать Map в одну строку. Функция Map.of которая позволяет это, была представлена только в JDK 9.
Пример статической инициализации в Java:
Но теперь Kotlin умеет делать так:
Еще одна вещь, которую я хочу выделить — Range операторы, которые делают вашу жизнь намного проще. Теперь вместо использования циклов for для простого обхода:
Вы можете делать в Kotlin так:
Или вот так в Swift:
Стоит еще упомянуть о кортежах (tuples). Они дают определенную свободу во взаимодействии с другими компонентами и помогают избегать создания дополнительных классов.
Итак, глядя на все эти новые «фичи» и многие-многие другие вещи, которые не упомянуты в этой статье — я бы предположил, что новая эпоха уже началась. Теперь всем новичкам, которые начинают свой путь в мобильной разработке, будут доступны все эти функции прямо «из коробки», и они смогут сократить затраты на рутинную разработку бизнес-логики и управление приложением. И это намного важнее, чем писать сотни строк для того чтоб сделать простой кусок работы. Конечно, раньше вы могли просто поставить и настроить дополнительную библиотеку, такую как PromiseKit, ReactiveCocoa, RxJava и т.п. Но я верю, что доступность этих парадигм и принципов — будет побуждать новых разработчиков использовать именно их, что приведет нас к светлому будущему. 🙂
Спасибо за внимание! Я надеюсь вам было интересно или, как минимум, это пост дал вам свежие идеи. Я пытался написать коротко, но если вам нужны более конкретные примеры и/или у вас есть предложения/замечания — пожалуйста, напишите в комментариях!