将界面投射到混凝土类型

Question

I am using the GeoJSON.NET library in my project. At some point I need to update a feature in my database. As a part of this, I need to access the coordinates of said Feature in order to store that information in the database as well. However looking at the source code on GitHub, the Feature class has the Geometry property as an IGeometryObject:

 public IGeometryObject Geometry { get; set; }

There exist multiple "shapes" according to GeoJSON specification, such as "Polygon", "Circle", "Point", etc. These specific shapes have been set up within the GeoJSON.NET project.

It's within those concrete types that I can actually dig in and access the various coordinates.

Currently I have this:

    public int CreateFeature(Feature feature)
    {
        int featureId = 0;
        var coordinatesDt = new DataTable();
        coordinatesDt.Columns.Add("Latitude");
        coordinatesDt.Columns.Add("Longitude");

        //we are loading a datatable with the coordinates.  This gets passed to a SQL server stored procedure as a single parameters to insert
        //all the nodes.
        LineString lineString = ((Polygon)feature.Geometry).Coordinates[0];
        foreach (var coordinate in lineString.Coordinates)
        {
            var row = coordinatesDt.NewRow();
            row["Latitude"] = ((GeographicPosition)coordinate).Latitude;
            row["Longitude"] = ((GeographicPosition) coordinate).Longitude;
            coordinatesDt.Rows.Add(row);
        }


        using (SqlConnection conn = new SqlConnection(_smmConnectionString))
        using (SqlCommand cmd = new SqlCommand("dbo.MyProc", conn))
        {
            //set up params, set up TVP and execute...
        }
        return featureId;
}

And here is a snippet from the Polygon class:

public List<LineString> Coordinates { get; set; }

So here in my code I'm actually doing an explicit downcast to a Polygon as I need to get to the Coordinates member of the Polygon class. I know I'm safe to do this only on the basis that these are the only "types" of shapes I'm using in my application, even though I know it's not necessarily best practice. However in the future if we were to use other types, this would totally break. I can go implement using "is or as" for type checking, but that still doesn't move me away from the notion of having to downcast.

So my question is what is the best way to go about this? I've read around about why to use interfaces and all that as members and/or parameters and that having to do an explicit downcast is "usually" bad practice and follows a bad design pattern... with the exception of rare cases. So do I fall into the "rare cases" here or is there a better way to go about this?

Answer 1

So you've decided you need to access an internal implementation detail of someone elses interface that you can't change.

Then you really have no choice but to take the cost of future maintenance. Yes, you have one of those rare cases..

To minimize the cost I strongly suggest you wrap all dangerous code in a helper class that operates on the published interface, so you don't mix it with your own business logic and clearly see where you need to make changes in the future.

Answer 2

Based on the GeoJSON.NET API, I think you do fall into one of these "rare cases". You have a few options for dealing with this:

1. Add a switch statement to your CreateFeature method that dispatches to a shape-specific method. Move the shape-specific functionality into the shape-specific method (see below).
2. Create a series of if..else if that do type checking for specific types (eg if (shape is Polygon) ProcessShape((Polygon)shape); ), and dispatch to a shape-specific method.
3. Use the visitor pattern to dispatch to a shape-specific method (although this would require that you modify the code of the GeoJSON.NET library).

Sample code for option 1:

switch (shape.Type)
{
    case GeoJSONObjectType.Polygon:
        ProcessShape((Polygon)shape);
        break;
    // additional shape support here...
}

Sample code for option 3:

// Add an AcceptVisitor method to the IGeometryObject interface:
public interface IGeometryObject
{
    GeoJSONObjectType Type { get; }
    void AcceptVisitor(IShapeProcessor visitor);
}
// Update each concrete shape class to include the new AcceptVisitor method:
public void AcceptVisitor(IShapeProcessor visitor)
{
    visitor.ProcessShape(this);
}
// Add an IShapeProcessor interface to the GeoJSON.NET project:
public interface IShapeProcessor
{
    void ProcessShape(Polygon shape);
    void ProcessShape(MultiPoint shape);
    void ProcessShape(LineString shape);
    // ...additional shape support...
}
// Update your existing class to implement the IShapeProcessor interface,
// and then change your code to do something like:
feature.Geometry.AcceptVisitor(this);

...and if you go with option 3, submit a pull request on GitHub so that everyone can benefit from your improvements!