​​Паттерны проектирования в Android разработке
#design #patterns #beginners

Паттерны проектирования — очень полезная штука, которая позволяет решать возникающие задачи оптимальным и уже проверенным способом. Кроме того, что такие подходы делают код чистым и легко расширяемым, они дают возможность лёгкого освоения вашего кода другим разработчикам. Ведь можно просто назвать используемый вами паттерн.

Если вы хотите связать существующие паттерны с Android-разработкой, то есть отличная статья, которая разбирает основные паттерны и описывает примеры, которые есть в Android. Вот некоторые из шаблонов: Builder, DI, Singleton, Factory, Adapter, Facade, Observer и многие другие.

Ну и обильные примеры кода также весьма радуют. Ссылка на статью тут.

​​Dependency Injection vs Service Locator
#patterns

Многие разработчики не задумываются о разнице этих двух подходов. На первый взгляд, они одинаковы, решают одну и ту же проблему — увеличивают декомпозицию кода. Или простым языком — уменьшают связность разных участков кода, что даёт нам улучшенную тестируемость, масштабируемость и простоту.

Более того, разница между подходами может становиться ещё менее заметной, когда мы используем библиотеки. Но давайте остановимся более подробно на каждом из подходов, рассмотрим пример, чтобы увидеть разницу и понимать достоинства и недостатки каждого из них.

Хорошее определение этих паттернов нашёл в этой статье.

🟢 если описать DI одним словом, то идеально подходит слово «отдавать». И в самом деле, при помощи DI мы просто даём нужные объекты другому объекту. В примере ниже классу House нужны объекты Door и Window, которые мы передаём ему в конструктор.

val window = Window()
val door = Door()
val house = House(window, door)

DI именно о том, что зависимости предоставляются нам кем-то. И нашему классу не важно, где этот кто-то данные зависимости берёт. Поэтому, мы и используем для DI конструктор, а не setter.

🔵 если мы описываем Service Locator одним словом, то идеально подходит слово «взять». Так, и есть: у нас есть какой-то класс (локатор, фабрика) у которого мы берём объекты, которые нужны нашему классу. В примере ниже, мы возьмём объект класса House напрямую из какого-то локатора и будем использовать его дальше.

val house = serviceLocator.get(House::class)

То есть локатор — это некая фабрика или контейнер, который наполняется готовыми объектами и из которого мы их получаем. Также нашему локатору не важно, как и кто положил эти объекты в него, его главная задача — предоставить объект, если он есть.

Современные библиотеки для внедрения зависимостей, такие как Dagger, Hilt, Koin, используют оба этих подхода в связке, хотя это и не всегда очевидно на первый взгляд. Но как мне кажется — это здорово, ведь каждый из них имеет свои плюсы, а подобное сосуществование уменьшает число недостатков.

​​Паттерн Builder в Kotlin
#patterns

Паттерн Builder используется для того, чтобы упростить создание объектов со сложной логикой создания или в случае наличия большого числа конструкторов.
По сути, этот правильно сконструированный Builder избавляет нас от того, чтобы думать о том, как создать объект, какой конструктор использовать, а вместо этого возвращает готовый объект или ошибку.

Этот паттерн широко используется в различных библиотеках или подходах. Например, в Android одним из самых распространённых примеров является создание AlertDialog при помощи Builder.

Вот хорошая статья, которая рассказывает о правильном создании объектов при помощи Builder. Пару тезисов оттуда:

0️⃣ Как ни странно, при создании объекта через Builder важно верно определить конструктор, который будет принимать параметры без которых объект не может существовать. В примере с AlertDialog таким параметром будет Context.
Например, в прошлых версиях Android у нас была возможность сделать Notification, который не показывался бы системой, а также приложение не падало с исключением – пример неверно созданного Builder.

1️⃣ Для каждого поля необходимо выставить параметр по умолчанию, например null. При использовании шаблона Builder рекомендуется сделать конструктор private, чтобы ограничить создание объекта только для внутреннего Builder.

2️⃣ Важно сделать верификацию объектов. Автор дает сразу 3 примера, где можно верифицировать добавляемые объекты: сразу после использования метода, при вызове метода build() или уже внутри объекта.
Хорошей практикой в данном примере будет использование 2 и 3 подхода одновременно.

3️⃣ Для того, чтобы сделать свой Builder можно использовать Kotlin DSL, который идеально подходит для этого паттерна. Кроме того, не стоит забывать о именованных параметрах, особенно когда вы указываете переменные одного типа.

В целом, этот паттерн один из самых популярных, и широко применяется на практике. Используйте его, если у вас есть большое число конструкторов, и вы заметно улучшите читаемость вашего кода. ✌️