ВВЕДЕНИЕ 3
1 ПОСТАНОВКА ЗАДАЧИ 5
1.1 Обзор существующих решений 5
1.2 Требования к программному продукту 6
2 РЕАЛИЗАЦИЯ ПРОГРАММНОГО ИНСТРУМЕНТА 8
2.1 Использованные технологии 8
2.2 Общая архитектура программного продукта 8
3 ПРИНЦИП РАБОТЫ БИБЛИОТЕКИ 11
3.1 Сбор информации о классах проекта 12
3.2 Генерация классов, внедряющих зависимости в корневые классы 14
3.3 Генерирование класса-фабрики 17
4 ФУНКЦИОНАЛЬНОСТЬ БИБЛИОТЕКИ 26
ЗАКЛЮЧЕНИЕ 30
СПИСОК ИСПОЛЬЗУЕМЫХ ИСТОЧНИКОВ 32
ПРИЛОЖЕНИЕ 34

Купить

С каждым днем мобильные приложения все больше становятся частью нашей жизни. Они получают все больше и больше функций, решают все больше повседневных задач.
Мобильные приложения следует разрабатывать с учетом их дальнейшего расширения. Именно поэтому важно придерживаться принципа Inversion of Control. Он подразумевает максимальную изолированность отдельных модулей приложения от реализаций других, что обеспечивает большую гибкость в разработке [1].
Одной из реализаций данного принципа является внедрение зависимостей - Dependency Injection. Этот процесс представляет собой передачу ответственности за построение требуемых модулю зависимостей специально предназначенному для этого внешнему механизму [2]. Другими словами, необходимые зависимости модулю предоставляются извне.
Также следование описанному принципу упрощает тестирование продукта. Если все компоненты системы сильно завязаны друг на друге, невозможно подменить какие-либо ее части, чтобы изолировать одну из них и проверить ее работоспособность. Некоторые модули могут быть, к примеру, слишком тяжеловесными, в таком случае тестирование будет занимать значительное время; либо же зависящими от внешних сервисов, изменение поведения которых может быть и вовсе невозможно.
Для реализации Dependency Injection используются такие инструменты, как Dagger 2, называемые DI-фреймворками [3]. Они предоставляют механизм для создания и внедрения зависимостей. При их использовании были выявлены следующие недостатки:
• Необходимость написания в большинстве случаев неоправданно большого количества кода для настройки - например, Dagger 2 требует написания 3-х дополнительных классов для каждого экрана приложения [4];
• Отсутствие автоматической конфигурации и автоматического поиска зависимостей;
• В случае простой настройки, которая не требует большого количества программного кода, работа приложения заметно замедляется из-за особенностей реализации библиотеки.
Целью данной выпускной квалификационной работы является разработка базовой функциональности DI-фреймворка, учитывающей эти недостатки.
Были поставлены следующие задачи:
1. Разработать механизм автоматического поиска реализаций зависимостей;
2. Разработать механизм создания экземпляров классов зависимостей;
3. Разработать механизм внедрения созданных экземпляров классов зависимостей.
Купить