КОДЕКС

За кулисами забытого адаптера в Geospatial

Применение шаблона проектирования адаптера в геопространственных данных

Почему используются шаблоны проектирования?

Использование шаблонов проектирования заключается в применении общих решений к аналогичным проблемам. Это не точные реализации кода, а шаблон для контекста данной проблемы.

Недостаточно избегать повторений, чтобы объяснить, почему существуют шаблоны проектирования. Шаблоны проектирования призваны укрепить четкие принципы. Наш интерес - внедрить эти принципы в нашу архитектуру.

По словам дядюшки Боба, цель - свести к минимуму усилия по созданию и обслуживанию наших систем. С этой целью мы используем шаблоны проектирования. Для достижения этой цели мы также стремимся откладывать решения (см. «Чистая архитектура» Боба Мартина).

Какие принципы подкрепляют шаблоны дизайна? Если вам интересно, вы можете прочитать о принципах SOLID:

  • Единственная ответственность
  • Открыто закрыто
  • Лисков замена
  • Разделение интерфейса
  • Инверсия зависимости

Проблемы с шаблонами дизайна

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

В моей серии статей о шаблонах геопространственного дизайна представлены типичные применения общих шаблонов. Эти конкретные примеры представляют собой введение для изучения общих шаблонов проектирования.

Почему мы должны использовать шаблон проектирования адаптера в геопространственных данных?

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

Наибольшая сложность в геопространственных данных заключается в наших данных. Алгоритмы просты, если сузить его до нашего варианта использования. Сложность заключается в разработке масштабируемого решения с множеством источников данных. Многие компании преуспевают за счет объединения источников данных. Они сотрудничают с организациями, генерирующими данные, и создают централизованный API. Затем они могут продать доступ к API. Мы можем применить их ту же стратегию в наших операциях по развитию.

Пример службы геокодирования

Геокодирование - это простой процесс связывания координат с входными данными. Наиболее распространенными входами являются адрес и общие имена. Для большинства приложений управления адресами и картографирования нашей целью является получение этих координат. Это должно быть просто, но ландшафт геокодирования намного сложнее, чем можно было бы ожидать. Поставщики используют разные способы представления точности или достоверности результатов геокодирования. У некоторых даже есть сложные условия (ToC) для хранения данных. Не существует универсального решения. Правильное решение для ваших нужд найти труднее, чем вы думаете.

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

Использование одного поставщика также может быть упущенной возможностью. Обоснованием может быть оптимизация цен или разработка лучшего в своем классе сценария с привлечением многих поставщиков. Шаблон адаптера может помочь вам избежать привязки к поставщику.

В схеме представлены два разных поставщика, но мы можем использовать их столько, сколько захотим.

Мы определяем стандарт нашего приложения с помощью интерфейса геокодирования. Наличие интерфейса геокодирования обеспечивает стабильность другим компонентам нашего приложения. Другие компоненты могут полагаться на интерфейс, зная, что мы контролируем вносимые в него изменения. Классы адаптера (или оболочки) являются реализацией нашего интерфейса геокодирования. Они адаптируют параметры интерфейса для вызова конкретного метода поставщика. В этом случае оба метода геокодирования поставщиков используют один и тот же параметр: однострочный адрес. Поскольку поставщики могут менять свои API друг от друга, мы определяем отдельные оболочки.

Пример данных о недвижимости

Централизованные данные о недвижимости труднодоступны из-за того, что они являются частной собственностью. В интересах риелторов хранить свою информацию при себе. Они будут делиться своей информацией только в интересах своих транзакций. Целый бизнес развился, чтобы позволить риэлторам сотрудничать: Служба множественного листинга (MLS). Для получения дополнительной информации о различных MLS в Канаде вы можете посетить эту ссылку.

Не все организации придерживаются одних и тех же соглашений в отношении данных о собственности. Созданы разные стандарты, последний из которых - РЕСО. Не все риэлторы соответствуют стандарту.

Мы можем использовать шаблон адаптера для интеграции различных источников данных о недвижимости. Стандарт RESO можно даже считать излишним для вашего картографического приложения. Достаточно иметь координаты и ссылку для каждой собственности. Адаптер снижает нашу уязвимость к новым стандартам и изменениям любых API.

Связаться

Когда вы использовали шаблон адаптера? Видите ли вы немедленные выгоды от его использования в вашем приложении?

Протяни руку! Я хотел бы услышать, какие еще шаблоны проектирования вы используете в своем геопространственном приложении!

Спасибо за прочтение.