Skip to content

Latest commit

 

History

History

06_inheritance

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 

Домашнее задание к занятию «2.3. ООП: композиция, наследование и интерфейсы»

Выполненное задание прикрепите ссылкой на ваши GitHub-проекты в личном кабинете студента на сайте netology.ru.

Важно: ознакомьтесь со ссылками на главной странице репозитория с домашними заданиями.

Если у вас что-то не получилось, оформите Issue. Шаблон для оформления.

Нужно сделать все задачи в одном репозитории.

Как сдавать задачи

  1. Создайте на вашем компьютере Gradle-проект.
  2. Инициализируйте в нём пустой Git-репозиторий.
  3. Добавьте в него готовый файл .gitignore.
  4. Добавьте в этот же каталог остальные необходимые файлы.
  5. Сделайте коммиты.
  6. Создайте публичный репозиторий на GitHub и свяжите свой локальный репозиторий с удалённым.
  7. Сделайте пуш и удостоверьтесь, что ваш код появился на GitHub.
  8. Ссылку на ваш проект прикрепите в личном кабинете на сайте netology.ru.
  9. Среди задач есть необязательные. Их можно не сдавать: на получение зачёта это не повлияет.

Задача №1. Nullable

Мы изучили Nullable, продолжим работать с постами и поддерживать код, который вы уже написали. Это важный навык для разработчика.

Доработайте первую задачу из предыдущей лекции так, чтобы в классе Post некоторые поля были Nullable (на ваш выбор).

Если вам не доступен ВКонтакте, вы можете воспользоваться сохранённой версией из каталога assets

Итог

  1. Data-класс Post.
  2. Внутри Post могут быть Nullable-свойства.
  3. WallService, который хранит посты в массиве.

Вы можете оформить это как Pull Request к предыдущему проекту (присылайте в личном кабинете ссылку на PR).

Важно: после обновлений WallService должна оставаться функциональной. Автотесты должны проходить.

Задача №2. Attachments

Следующая задача: разобраться с вложениями у постов - attachments (прямая ссылка/сохранённая копия).

В данном массиве могут храниться объекты разной структуры.

ВКонтакте их хранит вот так:

{
    "attachments": [
      {
        "type": "photo",
        "photo": {
            "id": 1,
            "owner_id": 1,
            "photo_130": "https://vk.com/some_photo_link",
            "photo_604": "https://vk.com/another_photo_link"
        }
      }, {
        "type": "video",
        "video": {
            "id": 1,
            "owner_id": 1,
            "title": "A Funny Video",
            "duration": 30
        }
      }
    ]
}

Формат называется JSON, с ним мы будем знакомиться позднее. В примере описано, что есть массив attachments, в котором лежат объекты (назовём их тип Attachment). В объектах массива есть поле type, а второе поле может быть различным (оно определяется на базе значения поля type: в первом случае Photo, во втором —Video). Для организации подобной структуры будет удобно применить наследование.

Возможны два варианта:

  • сделать Attachment интерфейсом,
  • сделать Attachment абстрактным классом.

В обоих вариантах нужно добавить в Attachment поле type, а после описать наследников Attachment, которые уже будут хранить специфичные данные (фото, аудио, видео). Эти данные (то, что вложено в наследников Attachment) лучше оформить в виде отдельных классов - Audio, Video и так далее. Т.е. для одного типа вложения будут отдельные классы: AudioAttachment и Audio. Не забывайте, что в Kotlin не обязательно каждый класс описывать в отдельном файле, а можно в одном описать сразу несколько, что будет особенно удобно в этой задаче.

Вам необходимо добавить к классу Post массив из объектов Attachment и описать классы Attachment, его наследников и классы для хранения данных о вложениях.

Поскольку типов вложений очень много, вам достаточно выбрать для реализации любые 5. Содержимое вложений можно посмотреть в документации или в сохраненных копиях в каталоге assets.

Вы можете оформить это как Pull Request к задаче №1 (присылайте ссылку в личном кабинете на PR).

Важно: после ваших обновлений WallService должна оставаться функциональной. Т.е. автотесты должны проходить.

Задача №3. Sealed-классы*

Важно: это не обязательная задача. Её выполнение не влияет на получение зачёта по ДЗ.

В Kotlin предыдущую задачу можно решить с помощью запечатанных (sealed) классов.

Вы можете определить фиксированную иерархию типов (количество типов вложений у вас фиксировано).

Тогда в выражениях типа when вам не придётся писать else.

Нужно почитать документацию и сделать Pull Request с реализацией на базе sealed-классов (вы можете подглядеть подсказку).

Подсказка

Не забывайте, что у всех наследников есть общее поле type. Для sealed-классов возможна следующая реализация:

sealed class Attachment(val type: String)

data class VideoAttachment(val video: Video) : Attachment("video")

fun main() {
    val attachment: Attachment = VideoAttachment("stuff")
    println(attachment.type)
}

Вы можете оформить это как Pull Request к задаче №1. Присылайте ссылку в личном кабинете на PR.

Важно: после ваших обновлений WallService должна оставаться функциональной,т.е. автотесты должны проходить.