Best practice when using multiple libraries with overlapping classes

Question

Consider the task:

1. Read a polygon from a KML file using library A
2. Intersect it with another polygon using library B
3. Calculate its area using library C

Each library has it's own Polygon class, and they are all equivalent. Which is the best practice when using all these classes? At the moment I first wrote this question I had implemented a method that converts a PolygonA instance into a PolygonB instance and vice-versa. But I wonder if it is the only way.

Clarification All libraries are third-parties'

Answer 1

I would either choose one polygon class and only use that class or build my own Polygon class to store all of them in.

At any rate, make sure your namespaces are aptly named so that you can differentiate between the two.

Why not merge the duplicated functionality?

Answer 2

One option that comes to mind is defining your own polygon class with copy constructors that accept the other types and methods on it to create instances of the other types from its data.

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

Doesn't really offer much advantage over the methods you have. However, I prefer it since it standardizes on one definition of polygon and then convert to the others as needed. Alternatively just pick one of the existing implementations as your base and just write methods to go between it and the other two.

Answer 3

The ideal solution depends a lot on your needs, but here's a suggestion.

Write your own Polygon class that internally stores the polygon as one of PolygonA/PolygonB/PolygonC. Your Polygon class will implement getArea() and getIntersection(polygon2) methods, which will translate the internal polygon into the appropriate type and call out to the right library.

This abstracts the libraries and polygon representations behind your own Polygon interface, which only needs to implement the portions of the APIs that you actually need. This will allow you to hide implementation details such as how many translations you implement (only 4 -- PolygonA->PolygonB->PolygonC->PolygonA? or all 6?) and how you store the polygon (pick one of the library types? use your own representation? store it in more than one representation to avoid translation overhead?)

Answer 4

Writing conversions is usually the only way if the libraries in question do not provide any adaptor interfaces. Any adaptors you make yourself will eventually have to be converted into the library's native representation to perform any algorithms on the geometry.

Another option is to make a wrapper class that caches each different A/B/C representation so that you only have to do the conversion to any given library once for each piece of geometry. And then all your code only deals with the wrapper class and just passes the appropriate representation to any relevant algorithms. The translation can be performed just-in-time before it is actually needed.

If you're working in a language with typedefs and/or nampespaces creating your own typedefs for each library's polygon type can make your life easier. For instance if each library just has its polygon type called 'Polygon' but it is placed into a specific namespace then:

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

If the libraries actually have naming conflicts then that's a real problem.