Question

My job is to fully rewrite an old library for GIS vector data processing. The main class encapsulates a collection of building outlines, and offers different methods for checking data consistency. Those checking functions have an optional parameter that allows to perform some process.

For instance:

std::vector<Point> checkIntersections(int process_mode = 0);

This method tests if some building outlines are intersecting, and return the intersection points. But if you pass a non null argument, the method will modify the outlines to remove the intersection.

I think it’s pretty bad (at call site, a reader not familiar with the code base will assume that a method called checkSomething only performs a check and doesn’t modifiy data) and I want to change this. I also want to avoid code duplication as check and process methods are mostly similar.

So I was thinking to something like this:

// a private worker
std::vector<Point> workerIntersections(int process_mode = 0)
{
    // it's the equivalent of the current checkIntersections, it may perform
    // a process depending on process_mode
}


// public interfaces for check and process
std::vector<Point> checkIntersections()  /* const */
{
    workerIntersections(0);
}


std::vector<Point> processIntersections(int process_mode /*I have different process modes*/)
{
    workerIntersections(process_mode);
}

But that forces me to break const correctness as workerIntersections is a non-const method.

How can I separate check and process, avoiding code duplication and keeping const-correctness?

Answer 1

Like you’ve noted, your suggestion will break const-correctness.
This is because your suggestion essentially includes wrapping the existing code with a new interface but not the redesign of internals. This approach has severe limitations as it’s directly affected by the underlying blocks.

Instead I would suggest you to redesign the existing code and just break the checkIntersections in 2 public methods that you need. The checkIntersections will include the checking part and processIntersections will include the call to checkIntersections and the processing code based on the result of checkIntersections.