3

私の仕事は、GIS ベクター データ処理用の古いライブラリを完全に書き直すことです。メイン クラスは建物のアウトラインのコレクションをカプセル化し、データの一貫性をチェックするためのさまざまな方法を提供します。これらのチェック関数には、何らかのプロセスを実行できるオプションのパラメーターがあります。

例えば：

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

このメソッドは、いくつかの建物のアウトラインが交差しているかどうかをテストし、交差点を返します。ただし、null 以外の引数を渡すと、メソッドはアウトラインを変更して交差を削除します。

私はそれがかなり悪いと思います（呼び出しサイトでは、コードベースに精通していない読者は、checkSomething と呼ばれるメソッドがチェックを実行するだけでデータを変更しないと想定します）、これを変更したいと思います。また、チェックとプロセスの方法はほとんど同じであるため、コードの重複を避けたいと考えています。

だから私はこのようなことを考えていました：

// 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);
}

しかし、workerIntersections は非 const メソッドであるため、const の正確性を破ることを余儀なくされます。

チェックとプロセスを分離して、コードの重複を回避し、const-correctness を維持するにはどうすればよいですか?

4

2 に答える 2

4

あなたが指摘したように、あなたの提案は壊れconst-correctnessます。これは、あなたの提案には基本的に、既存のコードを新しいinterfaceものでラップすることが含まれているためredesignです。このアプローチは、基礎となるブロックの影響を直接受けるため、深刻な制限があります。

checkIntersections代わりに、既存のコードを再設計し、必要な 2 つのパブリック メソッドを壊すことをお勧めします。にはcheckIntersectionsチェック部分processIntersectionsが含まれ、 への呼び出しとcheckIntersectionsの結果に基づく処理コードが含まれcheckIntersectionsます。

于 2012-12-11T14:43:08.503 に答える