whitepaper-1

最近思ったプログラミングの真理。

　　列挙子やdefineなどのシンボルに対して、
　　名前を変えただけのラッパーを作ると、
　　管理が大変になるだけでメリット無

関数のラッパーは必要な分だけあるのが理想的で、移植性やカスタマイズ性を向上させる効果がありますが、シンボルのラッパーは、移植性やカスタマイズ性を逆に減退させてしまうことがあります。むしろ予期せぬバグになる恐れすらあります。

私が使っている外部モジュールに、
　int func_test( A a )
という関数があったします。Aは外部モジュールで定義されている列挙子型とします。

このとき、私のモジュールに、
　int my_func_test( B b )
　{
　　/* bをaに置き換えたり、なんかいろいろしたり・・・ */

　　func_test(a);

　　/* なんかいろいろ */

　　return res;
　}
というようなラッパー用関数を作成したとします。また、Bは列挙子型で、Aのラッパーとします。

さて、外部モジュールに変更が入って、Aの中身が変化しました。具体的には、列挙子型のメンバーが減りました。このとき、どうなるでしょうか？　その変更にあわせて、私がBを変更するのを忘れていたら・・・致命的なバグになる可能性が生じます。私がやるべきことは、Aの変更にあわせてBを変更することと、上記のbをaに置き換えている部分を適切に変更することです。それをしないとどんな動作になるかわかったものではありません。

で、こういった変更が発生するのはどういうときか、なのですが、同じプロジェクトの中ではあまり発生しません。しかし、別のプロジェクトに移植するときに往々にして起こりえます。ハードが新しくなれば、そのハードのドライバーモジュールが"微妙に違う"のは当たり前です。前のハードでは対応していた列挙子が、今回のハードでは非対応となって削除されている、なんてことが起こるわけです。

ここで、私がもし大量のラッパー列挙子を抱えていた場合、そのような修正をミスなく全てやり尽くす必要があるわけです。


できるわけねー。


まぁ、私の担当部分は幸いなかなかに上手くできていて、リネームだけの無駄なラッパー列挙子は存在していません。２個下の層のシンボルをそのまま使っています。それでいいと思います。

私が考える本当に必要なラッパーは、関数、および、新たにシンボル化するための列挙子型です。もともと列挙子型になっているものに対して、新たな列挙子を用意するのは非常に危険だと私は思います。