プログラムを作るって難しい

Location::GeoToolのOO(オブジェクト指向)化バージョンを作っている。
が、本当にプログラムを作るのって難しい。

単に経緯度フォーマット変換・測地系変換・距離方位計算プログラムでも、どこまで再利用しやすく作るかというのを追求し出したら、ああでもないこうでもないときりがない。
特にOO化では、設計に思想が必要になってくるし、思想がちょっとずれてれば極度に「使えない」モジュールになっちゃうし…。

今はPerlで全部内部計算してるわけだけど、これじゃ遅くて使えん or もっと正確な計算アルゴリズムを、というような人がいた場合に、各計算エンジンだけ内部で差し替えられるようにしたり、
同じように対応している測地系や経緯度フォーマットも、データを動的に追加すればさくっと対応できるようにしたりしたいんだけど、
その辺を追求しようとするとああでもないこうでもない、となっちゃう。
単に技術的に可/不可の問題だけでなくて、後方互換の問題まで考えたりすると、この機能入れるのにこうしちゃうと後方互換なくなっちゃうなあ、今のうちならたいしてこのモジュール使ってる奴いないから今のうちに全部換えちゃうか、いやどうせ将来に渡って誰もほとんど使わねーよ、今それに拘泥してたらいつまでたってもFIXできねえから、もっといい方法考えてから実装したら、いやいやむしろ……てな感じ。

OO化でも、今の実装は、Jcodeあたりの発想を真似てて、
$obj->datum_wgs84->format_mapion->array
とかでデータ取るようにしているんだけど、単に
$obj->getdata('wgs84','mapion')
でいいんじゃないの？いや、それじゃ測地系とフォーマット片方だけ指定したい時どうするのよ、ハッシュリファレンスで渡す？それも格好悪いなあ
とか思ったり、

測地系計算やフォーマット変換も誤差の出る計算なので、いちいち変換してると
$obj->datum_wgs84->format_mapion->array
と
$obj->format_mapion->datum_wgs84->array
の間で同じになるはずの値が変わってくるとかの可能性も出てくる。
そこで、今はどれだけ変換のネストが深くなっても、オリジナルのデータを保持して、そこから最終のデータ出力メソッドが実行されたときに、まとめて変換するようにしている。
でも、一方で、別開発として
Class::DBIあたりのサブクラスで位置情報に関連したデータ構造を持ったデータベーステーブル(GISデータベースではないもの)上で、位置ベースの汎用検索とかを実装したモジュールを作りたいと思ってるんだけど、
それとLocation::GeoToolの連携を考えたりした場合、クラスとしてデフォルトの測地系・フォーマットを持っていて、どんな値を入れても自動で即座にデフォルトの測地系・フォーマットに変換されて、Class::DBIを通じてデータベースにさくっと突っ込める、という形にした方がスマートかなと考えたり…。

考えども考えども、悩みは尽きぬ。
問題を先送りにしちゃうと後で後方互換をなくさざるを得なかったり、もしくは後方互換を保つためにえらい苦労をしないといけなくなったりしてしまう。
体に不安を抱えているだけに後で苦労が増えるのがとにかく怖いので、最初に考えすぎて今度はなかなか動けなくなってしまう。

誰か相談…ていうかね、別にそんな深刻な話ではなくて軽く「これどうかねえ」レベルで意見を聞ける同レベル以上の人間が一人そばにいるだけで、全然違うんだけどなあ…。
ないものねだりしてもしょうがないけど。