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

Question

Рассмотрим задачу:

1. Чтение многоугольника из файла KML с использованием библиотеки A
2. Пересечь его с другим многоугольником, используя библиотеку B
3. Рассчитать его площадь, используя библиотеку C

Каждая библиотека имеет свой собственный класс Polygon, и все они эквивалентны. Какова наилучшая практика при использовании всех этих классов? В тот момент, когда я впервые написал этот вопрос, я реализовал метод, который преобразует экземпляр PolygonA в экземпляр PolygonB и наоборот. Но мне интересно, если это единственный путь.

Пояснение Все библиотеки являются сторонними

Answer 1

Запись преобразований обычно является единственным способом, если в рассматриваемых библиотеках нет интерфейсов адаптера. Любые адаптеры, которые вы сделаете сами, в конечном итоге должны быть преобразованы в собственное представление библиотеки для выполнения любых алгоритмов по геометрии.

Другой вариант - создать класс-обертку, который кэширует каждое различное представление A / B / C, так что вам нужно выполнить преобразование в любую заданную библиотеку только один раз для каждого элемента геометрии. И тогда весь ваш код имеет дело только с классом-оберткой и просто передает соответствующее представление любым соответствующим алгоритмам. Перевод может быть выполнен точно в срок, прежде чем он действительно понадобится.

Если вы работаете на языке с typedefs и / или nampespaces, создание ваших собственных typedefs для каждого типа многоугольника библиотеки может облегчить вашу жизнь. Например, если каждая библиотека имеет свой тип многоугольника с именем «Многоугольник», но она помещается в определенное пространство имен, тогда:

typedef A::Polygon APolygon;
typedef B::Polygon BPolygon;
typedef C::Polygon CPolygon;

Если библиотеки действительно имеют конфликт имен, то это реальная проблема.

Answer 2

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

public class MyPolygon
{
    public MyPolygon(LibAPolygon polygon) { /* copy data */ }
    public LibAPolygon CopyToLibAPolygon() { ... }
    // repeat for each library
}

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

Answer 3

Идеальное решение во многом зависит от ваших потребностей, но вот предложение.

Напишите свой собственный класс Polygon, который внутренне хранит полигон как один из PolygonA / PolygonB / PolygonC. Ваш класс Polygon будет реализовывать методы getArea () и getIntersection (polygon2), которые преобразуют внутренний многоугольник в соответствующий тип и вызывают нужную библиотеку.

Это абстрагирует библиотеки и представления полигонов за вашим собственным интерфейсом Polygon, который должен реализовывать только те части API, которые вам действительно нужны. Это позволит вам скрыть детали реализации, например, сколько переводов вы реализуете (только 4 - PolygonA-> PolygonB-> PolygonC-> PolygonA? Или все 6?) И как хранить многоугольник (выбрать один из типов библиотек? использовать свое собственное представление? сохранить его в более чем одном представлении, чтобы избежать затрат на перевод?)

Answer 4

Я бы либо выбрал один класс многоугольников и использовал бы только этот класс, либо построил свой собственный класс многоугольников, чтобы хранить их все.

В любом случае, убедитесь, что ваши пространства имен точно названы, чтобы вы могли различать их.

Почему бы не объединить дублированный функционал?