sealed class kotlin что это
Запечатанные классы (sealed)
Добавление модификатора sealed к суперклассу ограничивает возможность создания подклассов. Все прямые подклассы должны быть вложены в суперкласс. Запечатанный класс не может иметь наследников, объявленных вне класса.
В методе eval() при использовании when не пришлось использовать ветку else, так как sealed позволяет указать все доступные варианты и значение по умолчанию не требуется.
Если позже вы добавите новый подкласс, то выражение when будет ругаться и вы быстро вспомните, что нужно добавить новый код в программу.
По умолчанию запечатанный класс открыт и модификатор open не требуется. Запечатанные классы немного напоминают enum.
Пример: Продам кота дёшево
Создадим запечатанный класс AcceptedCurrency и три подкласса на его основе. Обратите внимание, что сейчас Kotlin разрешает объявлять подклассы не внутри запечатанного класса, а на одном уровне (для сравнения смотри старые примеры выше).
В классе активности создадим список принимаемых валют для покупки котят и применим его к адаптеру выпадающего списка.
Если запустить пример прямо сейчас, то в выпадающем списке увидим служебную информацию о классах. Не совсем то, что мы хотели увидеть.
Внесём изменения в запечатанный класс, чтобы у него появилось новое свойство.
Если вы пропустите какой-то подкласс в выражении when, то компилятор будет ругаться. Это удобно, когда вы будете вносить изменения в код.
Поменяем код для адаптера.
Теперь названия выводятся нормально.
Установим зависимость валют от рубля. Создадим в запечатанном классе абстрактное свойство valueInRubels. После этого студия потребует дополнить код у всех подклассов.
Добавим в класс ещё одну переменную ammount и функцию для подсчёта общей суммы.
Напишем код для щелчка кнопки. Вам нужно ввести минимальную и максимальную цену в любой валюте для одного котёнка, а кнопка покажет цену в рублях. Если вы увидите, что покупатель из Америки, то выставляете ценник в долларах. Если покупатель из непонятной страны, то ставьте тугрики (какая вам разница?).
В примере мы выставили цену от 2 до 3 долларов за котёнка (что-то мы продешевили) и сразу видим, сколько заработаем в рублях.
Изолированные классы
Изолированные классы и интерфейсы позволяют выразить ограниченные иерархии классов, которые обеспечивают больший контроль над наследованием. Во время компиляции известны все прямые наследники изолированного класса. Никакие другие наследники не могут появиться после компиляции модуля с изолированным классом. Например, сторонние клиенты не могут расширить ваш изолированный класс в своем коде. Таким образом, каждый экземпляр изолированного класса имеет тип из ограниченного набора, который известен при компиляции этого класса.
То же самое справедливо для изолированных интерфейсов и их реализаций: новые реализации не могут появиться после компиляции модуля с изолированным интерфейсом.
Изолированные классы похожи на enum-классы: набор значений enum типа также ограничен, но каждая enum-константа существует только в единственном экземпляре, в то время как наследник изолированного класса может иметь несколько экземпляров, которые могут нести в себе какое-то состояние.
В качестве примера рассмотрим API библиотеки. Вероятно, он будет содержать классы ошибок, чтобы пользователи библиотеки могли обрабатывать возникающие ошибки. Если иерархия таких классов ошибок включает интерфейсы или абстрактные классы, видимые в общедоступном API, то ничто не препятствует их реализации или расширению в клиентском коде. Однако библиотека не знает об ошибках, объявленных за её пределами, поэтому не может обрабатывать их согласованно с помощью собственных классов. Благодаря изолированной иерархии классов ошибок авторы библиотек могут быть уверены, что им известны все возможные типы ошибок, и никакие другие не могут появиться позже.
Чтобы описать изолированный класс или интерфейс, укажите модификатор sealed перед его именем.
Сам по себе изолированный класс является абстрактным, он не может быть создан напрямую и может иметь абстрактные компоненты.
Расположение прямых наследников
Прямые наследники изолированных классов и интерфейсов должны быть объявлены в том же пакете. Они могут быть верхнего уровня или вложены в любое количество других проименованных классов, проименованных интерфейсов или проименованных объектов. Наследники могут иметь любую видимость, если они совместимы с обычными правилами наследования в Kotlin.
Наследники изолированных классов должны иметь правильные имена. Они не могут быть локальными или анонимными объектами.
Эти ограничения не применяются к непрямым наследникам. Если прямой наследник изолированного класса не помечен как изолированный, он может быть расширен любыми способами, разрешенными его модификаторами.
Наследование в мультиплатформенных проектах
Если изолированный класс объявлен как expected в общем модуле и имеет actual реализации в платформенном модуле, как ожидаемая, так и актуальные версии могут иметь наследников в своих модулях. Более того, если вы используете иерархическую структуру, вы можете создавать наследников в любом исходном наборе между expect и actual объявлениями.
Изолированные классы и выражение when
Sealed classes
Sealed classes and interfaces represent restricted class hierarchies that provide more control over inheritance. All direct subclasses of a sealed class are known at compile time. No other subclasses may appear after a module with the sealed class is compiled. For example, third-party clients can’t extend your sealed class in their code. Thus, each instance of a sealed class has a type from a limited set that is known when this class is compiled.
The same works for sealed interfaces and their implementations: once a module with a sealed interface is compiled, no new implementations can appear.
In some sense, sealed classes are similar to enum classes: the set of values for an enum type is also restricted, but each enum constant exists only as a single instance, whereas a subclass of a sealed class can have multiple instances, each with its own state.
As an example, consider a library’s API. It’s likely to contain error classes to let the library users handle errors that it can throw. If the hierarchy of such error classes includes interfaces or abstract classes visible in the public API, then nothing prevents implementing or extending them in the client code. However, the library doesn’t know about errors declared outside it, so it can’t treat them consistently with its own classes. With a sealed hierarchy of error classes, library authors can be sure that they know all possible error types and no other ones can appear later.
To declare a sealed class or interface, put the sealed modifier before its name:
A sealed class is abstract by itself, it cannot be instantiated directly and can have abstract members.
Constructors of sealed classes can have one of two visibilities: protected (by default) or private :
Location of direct subclasses
Direct subclasses of sealed classes and interfaces must be declared in the same package. They may be top-level or nested inside any number of other named classes, named interfaces, or named objects. Subclasses can have any visibility as long as they are compatible with normal inheritance rules in Kotlin.
Subclasses of sealed classes must have a proper qualified name. They can’t be local nor anonymous objects.
enum classes can’t extend a sealed class (as well as any other class), but they can implement sealed interfaces.
These restrictions don’t apply to indirect subclasses. If a direct subclass of a sealed class is not marked as sealed, it can be extended in any ways that its modifiers allow:
Inheritance in multiplatform projects
There is one more inheritance restriction in multiplatform projects: direct subclasses of sealed classes must reside in the same source set. It applies to sealed classes without the expect and actual modifiers.
If a sealed class is declared as expect in a common source set and have actual implementations in platform source sets, both expect and actual versions can have subclasses in their source sets. Moreover, if you use a hierarchical structure, you can create subclasses in any source set between the expect and actual declarations.
Sealed classes and when expression
The key benefit of using sealed classes comes into play when you use them in a when expression. If it’s possible to verify that the statement covers all cases, you don’t need to add an else clause to the statement. However, this works only if you use when as an expression (using the result) and not as a statement:
when expressions on expect sealed classes in the common code of multiplatform projects still require an else branch. This happens because subclasses of actual platform implementations aren’t known in the common code.
Android RecyclerView с использованием котлиновских sealed классов
RecyclerView — это один из самых лучших инструментов для отображения больших списков на Android. Как разработчики, вы, скорее всего понимаете о чем я говорю. У нас есть много дополнительных фич, таких как шаблоны вью холдеров, сложная анимация, Diff-Utils колбек для повышения производительности и т. д. Такие приложения, как WhatsApp и Gmail, используют RecyclerView для отображения бесконечного количества сообщений.
Почему sealed классы Kotlin?
После появления Kotlin для разработки приложений под Android наши подходы к реализации кода кардинально изменились. То есть такие фичи, как расширения, почти заменили потребность в поддержании базовых классов для компонентов Android. Делегаты Kotlin внесли изменения в нашу работу с сеттерами и геттерами.
Вдохновившись этой статьей, я хочу показать вам реализацию типов представлений в RecyclerView с использованием sealed классов. Мы постараемся развить сравнение случайных чисел или лейаутов до типов классов. Если вы фанат Kotlin, я уверен, что вам понравится эта реализация.
Создание sealed классов в Kotlin
Первое, что нам нужно сделать при этом подходе — это создать все классы данных, которые мы намерены использовать в адаптере, а затем необходимо связать их в sealed классе. Давайте создадим группу классов данных:
Это несколько классов данных, которые я хотел отобразить в списке, основываясь на данных с серверов. Вы можете создать столько классов данных, сколько захотите. Этот подход хорошо масштабируется.
То, что мы можем работать с состояниями загрузки, хедерами, футерами и многим другое без написания дополнительных классов — это одно из крутых преимуществ данного метода. Вы скоро узнаете, как это сделать. Следующим шагом является создание sealed классов, содержащих все необходимые классы данных:
Sealed класс с пользовательскими моделями
Sealed класс с хидером и футером
На этом этапе заканчивается реализация нашего sealed класса.
Создание адаптера RecyclerView
В приведенном выше коде показана базовая реализация адаптера RecyclerView без какой-либо логики sealed классов. Как можно заметить, мы объявили sealed классы arraylist (UIModel). Следующим шагом является возврат соответствующего типа представления на основе позиции:
Сравнение модели sealed класса для получения типа представления
Теперь, когда мы успешно вернули правильный лейаут на основе модели sealed класса, нам нужно создать соответствующий ViewHolder в функции onCreateViewHolder на основе viewtype :
Создание вью холдера с учетом типа представления из sealed классов
Последний шаг — обновить вью холдер на основе текущих данных элемента, чтобы адаптер мог отображать данные в пользовательском интерфейсе. Поскольку у адаптера есть несколько представлений, мы должны классифицировать тип, а затем вызвать соответствующий ViewHolder :
После объединения всех частей кода, он выглядит так:
Финальная версия адаптера
Публикация данных в адаптер RecyclerView
DiffCallback
«DiffUtil — это вспомогательный класс, который может вычислять разницу между двумя списками и выводить список операций обновления, который преобразует первый список во второй». — Android Developer
Реализация diffcallback не является обязательной, но она повысит производительность, если вы работаете с большими наборами данных. Итак, чтобы реализовать difCallback в нашем адаптере, нам нужно различать модели и сравнивать нужные переменные:
Это все. Надеюсь, эта статья была для вас полезной. Спасибо за внимание!
Всех желающих приглашаем на двухдневный онлайн-интенсив «Делаем мобильную мини-игру за 2 дня». За 2 дня вы сделаете мобильную версию PopIt на языке Kotlin. В приложении будет простая анимация, звук хлопка, вибрация, таймер как соревновательный элемент. Интенсив подойдет для тех, кто хочет попробовать себя в роли Android-разработчика.
>> РЕГИСТРАЦИЯ
Советы и трюки для программирования на языке Kotlin
Полезные трюки, с которыми проще писать на языке Kotlin. В этой статье рассмотрим изолированные классы и функцию when() для перестановок.
Изолированные классы в языке Kotlin
Изолированный класс – не новое понятие для программирования: это довольно известная концепция. Такие классы используются для отражения ограниченных иерархий классов, когда значение может иметь тип только из ограниченного набора.
Изолированные классы представляют собой расширение enum-классов: набор значений enum-типа также ограничен, но каждая enum-константа существует только в единственном экземпляре, в то время как наследник изолированного класса способен иметь множество экземпляров, которые могут нести в себе какое-то состояние.
Kotlin предоставляет специальное ключевое слово sealed для создания закрытых классов:
На первый взгляд может показаться, что этот код ничего не делает, кроме объявления sealed-класса. Чтобы глубже разобраться с тем, что происходит, воспользуемся инструментом IntelliJ IDEA Kotlin Bytecode.
Найдем Kotlin Bytecode
Декомпилируем байткод Kotlin в Java
После преобразования можно ознакомиться с представлением кода на Java:
Изолированные классы созданы специально для наследования. Кроме того, компилятор Kotlin позволяет использовать подклассы класса Response в качестве кейсов функции when(). Структуры, наследуемые из изолированного класса, могут быть объявлены как данные и даже как объект.
Экземпляр Response можно использовать без каких-либо дополнительных преобразований:
Чтобы напомнить себе, как выглядел бы код без sealed-классов и Kotlin в целом, давайте еще раз воспользуемся IntelliJ IDEA Kotlin Bytecode:
Использование when() для перестановок
Мы уже сталкивались с возможностями функции when() выше. Давайте теперь представим, что необходимо реализовать функцию, которая принимает два перечисления и создает неизменяемое состояние.
Enum-класс Employee описывает все роли, которые могут быть найдены в компании XYZ, а enum-класс Contract содержит все виды трудового договора. На основе двух этих перечислений необходимо вернуть правильный SafariBookAccess. Кроме того, функция должна создавать все состояния для данных перечислений. В качестве первого шага создадим прототип подписи функции, создающей состояние:
Теперь определим структуру SafariBookAccess, используя волшебное sealed:
Осталось заняться основной задачей функции access() – перестановкой:
Выглядит здорово, но можно ли сделать так, чтобы код выглядел более по котлински? Вот на что стоит обратить внимание:
Теперь функция выглядит более чистой и короткой, но в языке Kotlin есть еще одна приятная возможность – полностью избежать объявления Pair: