Это еще один простой структурный паттерн. Он помогает в ситуациях, когда данные на выходе из одной системы не совпадают с данными для входа в другой системе. Если отойти от разработки, то мне было проще всего понять на примере с usb-проводами, которые многие используют для зарядки телефонов. У нас есть ноутбук и телефон и с каждой стороны разные типы разъемов. Наш провод — это как раз и есть адаптер, который помогает совместить два несовместимых устройства (ноутбук и телефон).
И в этом паттерне очень простая схемка:
Как мы реализовываем:
- Создаем какой-то интерфейс, метод(ы) которого будет вызывать клиент. Клиент — наш телефон. Интерфейс — наш USB-провод;
- Создаем класс адаптер, который переопределяет метод(ы) интерфейса и где есть приватный класс стороннего апи или чего-либо, с чем надо совместить (ноутбук). Тут в виде адаптера будут внутренности USB-провода, где происходит вся магия;
- Готово. На схемке есть еще Api (ноутбук), но обычно он находится в какой-то сторонней библиотеке или уже реализован у нас.
Зачем вообще всё это делать и почему бы просто не поменять апи? Просто добавили бы в ноутбук разъем для телефона. Но дело в том, что ноутбук могут использовать и владельцы айфонов, и владельцы андроидов, и вообще противники телефонов. Невозможно добавить все типы разъемов и удовлетворить всех. Так и с апи: его могут использовать разные клиенты, которые могут ожидать разные форматы. Мы ждем json, а кто-то ждет как раз xml. А еще у нас может не быть доступа к сторонней библиотеке и тогда остается только адаптироваться. :)
Дубль статей в телеграмме — https://t.me/android_junior
Мои заметки в телеграмме — https://t.me/android_junior_notes
