パイプラインを処理するためのモジュール式アーキテクチャ

私はC ++で実装するシステムのアーキテクチャを設計しようとしていますが、人々が良いアプローチを考えたり、これまでに設計したアプローチを批評したりできるのではないかと考えていました。

まず、一般的な問題は画像処理パイプラインです。これにはいくつかの段階が含まれており、目標は高度にモジュール化されたソリューションを設計することです。これにより、任意の段階を簡単に入れ替えてカスタムコードに置き換えることができます（ユーザーが知っている場合は速度を上げることができます）。特定の段階が彼または彼女の問題において特定の方法で制約されていること）。

現在の考え方は次のようなものです：

struct output; /*Contains the output values from the pipeline.*/

class input_routines{
    public:
    virtual foo stage1(...){...}
    virtual bar stage2(...){...}
    virtual qux stage3(...){...}
    ...
}

output pipeline(input_routines stages);

これにより、人々はinput_routinesをサブクラス化し、必要なステージをオーバーライドできます。とは言っても、私は以前このようなシステムで働いたことがあり、サブクラス化やデフォルトのものが面倒になりがちで使いにくいことがわかったので、自分で書くのはめまいがしません。また、さまざまなステージ（6または7がある）がデフォルトのテンプレートパラメーターになる、よりSTL的なアプローチについても考えていました。

誰もが上記のパターンの批評、テンプレートアプローチに関する考え、または頭に浮かぶ他のアーキテクチャを提供できますか？

設計は、さまざまなステージが実際に行うことに大きく依存しています。私は主に、純粋でない仮想関数（抽象クラ​​ス）よりも純粋な仮想関数を好みます。

一般的なステージは、抽象サブクラスにグループ化できます。メインの抽象クラスから派生することで、引き続きすべてのステージを調整できますが、サブクラスから派生することで、すでに記述されている既存の動作を再利用できます。仮想メソッドについて述べたように、混乱が少なくなる傾向があります。

異なるステージが（パイプライン全体の外で）単独で存在する可能性がある場合は、この動作を分離するクラスを作成することも検討してください。

おそらく、ステージを実装するファクトリ内のファンクタのリストを作成します。疑似コード：

functorFactory() {
  return [ foo(), bar(), baz() ]
}

ユーザーはファクトリを再実装するか、ファンクタのリストを操作するだけです。疑似コード

myFactory() {
  return [ foo(), myBar() ]
}

または

myFactory() {
  return functorFactory()[2] = myBar()
}

セットアップが完了すると、最後の結果を使用して各ファンクターを呼び出すことができます。

Haskellに実装されているMonadsを見てください。これにより、設定方法がわかります。Haskellはこの種のことを本当に正しく理解しています。

中間タイプを定義します。すべての画像はこの形式に変換されます。各ステージは中間体を取り、中間体を返します- 同じものではなく、新しいもの。

ステージは次のようになります：

Intermediate DoSomething(const Intermediate &i);

継承ベースのソリューションは、問題へのかなり明白なマップ（3Dワールドのオブジェクトなど）でない限り、通常は避けます。