Создавайте базовые бесплатные приложения для Android, используя повторно используемые делегаты.
Одна из вещей, которую мы привыкли делать при запуске новых проектов Android, — это устанавливать его базовые классы, такие как BaseActivity, BaseFragment, BaseViewModel, BaseRecyclerAdapter…. и так далее. Итак, у нас есть структура, которой нужно следовать, а не повторять наш код снова и снова.
Но постойте, это соответствует принципам SOLID? Как насчет принципа единой ответственности? Как насчет больших басов God? Как насчет всех дочерних классов, имеющих функциональные возможности, которые они могут вообще не использовать? Как насчет внесения изменений в этот базовый класс? Это сломает все классы, которые унаследованы от него? Что, если нам нужны разные варианты этого базового класса?
Мы видим, что польза от баз сопряжена со многими проблемами и высокими рисками. Любое изменение этой базы требует изменения большого количества классов, большого количества времени, больших усилий и множества тестов… потому что вещи тесно связаны.
В общем, для повторного использования нашего кода у нас есть несколько вариантов отношений:
1- Наследование
Он является производным от одного класса к другому, поэтому отношение таково: «есть-а», как и кошка, это животное. В общем, следует избегать этого в пользу ассоциации, если мы можем. Кроме того, в ООП мы не можем наследовать от нескольких классов.
Подробнее об этом читайте в Проблеме бриллианта.
2- Ассоциация
Он определяет класс как сумму его частей (других классов). Поэтому всякий раз, когда нам нужна какая-то функциональность, мы можем вызывать другие объекты и использовать их функциональность в нашем классе. Здесь соотношение: «есть-а», как у машины есть-двигатель.
Ассоциация может быть достигнута:
1- Агрегация
Это слабая ассоциация, поскольку у каждого сотрудника есть карта доступа. Сотрудники могут существовать сами по себе, так и карта доступа.
2- Состав
Это сильная ассоциация, как в доме есть комната, но комната не может существовать без дома. Таким образом, жизненный цикл комнаты контролируется домом.
После всего этого, можем ли мы использовать ассоциацию так же, как наследование? Да, именно здесь сияют Делегаты!
Начнем с веселой части. Я продемонстрирую, как делегаты работают с добавлением функциональности панели инструментов в действие Android.
Чтобы применить концепцию делегата, мы должны выполнить 4 шага:
Шаг 1
Определите функциональность, за которую отвечает этот делегат.
Шаг 2
Реализуйте этот функционал.
Шаг 3
Создайте экземпляр любой из этих реализаций делегата.
Шаг: 4
Заставьте свой класс реализовать этот интерфейс делегата, а затем делегируйте его функциональность.
Бонус:
Это много добавленного кода. Можем ли мы упростить вещи?
Мы можем точно! К счастью, в Kotlin есть встроенная поддержка делегатов! Это магия ключевого слова «by».
Давайте посмотрим, что в действии:
Я надеюсь, что эта статья поможет вам получить более чистый код, который легко поддерживать.
Дополнительные сведения см. вофициальной документации Kotlin.
Спасибо, что прочитали, и следите за новостями!
