C言語用バッチ処理フレームワーク

バッチ処理にもパターンがあります。メインフレームで業務バッチを担当された方の中ではスケルトンと命名されていたかと思います。COBOL系ではオンライトランザクション処理にもスケルトンを適用されていたと思います。

スケルトンについて説明しましょう。

オンライントランザクションについては、COBOL系に精通した方で無いとイメージしづらいので、バッチプログラムで説明します。

バッチプログラムは帳票プログラムと似ているのですが、通常

• (1) 再実行ポインタの管理
• (2) DBコネクションの取得
• (3) コミット管理
• (4) バッチ処理対象となるデータの準備
• (5) 対象データ全てに対しデータ判定・データ加工を繰り返し実施
• (6) DBコネクションの解放

といった処理パターンが考えられます。

※クリックで拡大されます↑

スケルトンではこういったパターンのプログラムソースを事前に用意し、それに穴埋め方式で業務ロジックを追加します。

この方式の欠点は、ひとたび実装チームの手に渡ったら最後、同じロジックがプログラムの数分存在し、スケルトンレベルの変更はワンパターンとはいえ、多大なソースの変更が発生することです。
もっともコピー句をうまく使ったりといった工夫はされているとは思います。
オブジェクト指向であれば、これぞフレームワークの守備範囲となります。
しかし、C言語はオブジェクト指向をサポートしていません。では本当にフレームワーク的に実装できないのでしょうか。

1980年代からC++に精通されている方は思い出してください、初期のC++はC言語のフロントエンドであったことを。C++のソースをCソースにトランスレートしてからCコンパイルしていたのです。
つまり、C言語で継承を実現することは難しいことではないのです。
ここではC言語で継承を実現する方法を詳しく述べるつもりはありません。
Motifなどでコールバック関数を経験された方も多いでしょう。コールバックを利用すればスケルトン部分をフレームワークとして提供し、業務固有処理はコールバック関数として実装してもらえばよいのです。

オブジェクト指向でよく言われる、
「業務ロジックから共通ルーチンのように呼んでもらうのではなく、こちらから業務ロジックを呼び出そう。」
これこそフレームワークの第一歩です。