静的モデリングとモデルレス

なるほど、リアルな現場の知恵、勉強になります。

プログラマの方にとっては、Date型を使わないことへの疑問があるようです。
Date型でなく、なぜわざわざyyyymmdd形式で日付のデータを扱うのかというと、自治体の業務においては必要な場合があります。

日付のデータをyyyymmddで扱う理由 - ある地方公務員電算担当のナヤミ

これで思うことがふたつ。


ひとつは、id:alittlethingさんが示した理由に対する、私の元エントリの考え方の延長。

ひとつには、ユーザである一般職員は業務を行ううえでExcelにデータを切り出して扱うことが多い、ということがあります。

それはシステム境界でのインタフェースについての話で、システム内でのデータの持ち方とイコールではないような。ただ、ユーザが勝手にDB直繋ぎしちゃうようなシステムもあるから、リアリティの点でどこまでかは微妙。

実在しない日付のまま処理せざるを得ない時があります。こういうときには、Date型でデータを持っていると処理不能になりますので

それは、システムの要件に対して、使用したDate型のモデルが適切ではないという問題で、その要件に合うDate型を使うのが解ではないかと。これも、リアリティの点でどこまでかは微妙。


そして、もうひとつ。

それは、私の元エントリの考え方の延長が、リアリティの点で微妙であると言うこと。とくにふたつめのモデルの話。


プログラムを書く時、システムを作る時、そこには必ず大小のモデルの構築がある。構築されるのは、設計時のモデルであり、プログラミング・システム構築は静的モデリングと言える。しかし、プログラムもシステムも生きている。

設計時にはOpen-Closed Principleで申し分ない設計をしていても、想定外の変更で結局モデルを修正する事は、容易に発生する。全体に広くそのモデルへの依存がある場合、そのモデルが満たさない新たな(あるいは当初見落としていた)要求は、膨大な修正コストを強制する。


この場合、Date型を使ってたけど、実はもう一段上の、存在有無を問わない年月日の組み合わせの型が必要だった、と。でも、全体でDate型で使いまくりだと後の祭り。…そこで、抽象モデルですよ。具体型なんて使っちゃダメ。

いやいや、抽象モデルだってモデルであって、結局それは設計時の静的モデル。根本的にはOpen-Closed Principleと同じ話。で、日付を文字列で扱うってのはある意味、究極の抽象化ではある。モデルレス。これを付き進めれば、全てのデータは、byte列で扱えばいかなる制約も受けない。なんでもすべて struct {void* data; int length;}; 。完璧。なんでもできる!。素晴らしい。…ほんとか?



…書いてるうちにgdgdになったので、あとで断りなく直すかも。


(そうかんがえると、Haskellは具体型べったりで*1、生きたプログラムに厳しい言語だなぁ、改めて。)

*1:ADTはあるけど