契約プログラミングとは
ということではない。
概要
プログラミングにおける契約
プログラミング言語では(実用性を無視したネタ言語を除き)、便利にプログラミングできるよう様々な工夫がこらされている。また、人為的ミスを防ぐための機構も(便利さと引き換えになることも多いが)張り巡らされている。
たとえば静的型付け言語では、型が合わない代入や引数・戻り値はエラーになりコンパイルや実行ができないようになっている。これはプログラミング上の制約でもあるが、同時に型の誤りを防ぐための機構でもあるのだ。
しかし、言語仕様でいくら規定したところで、それだけでは表現できない制約もある。たとえば、%で計算するので引数が0以上100以下の整数でなければならないとか、計算が失敗した時は戻り値が-1になるとかである。
こういったプログラミング言語で表現することが難しい仕様は、APIドキュメントに「契約」として記載するやりかたが一般的である。
特に他人が作ったライブラリを使用する場合など、ひとたびライブラリを使用したならば、そのライブラリのドキュメントに記載された契約がライブラリ作成者との間で成立したことになるのである。
もっとも、通常のAPIドキュメントに書かれている契約の範囲はそのライブラリの使用に関するものに限られるので、契約が成立したからといって、魔女になってしまうわけでもなければ、魔法少女になれるわけでもない。IT土方になってしまうかどうかは、うっ、頭が...
契約プログラミング
APIドキュメントによる「契約」は文章なのでどんなことでも書けてしまう反面、曖昧さが残りやすい。なによりも使う側がその契約を守ってくれる保証がどこにもない。
そこで、言語仕様で契約が守られることを保証しようという考え方が契約プログラミングである。
他のメジャー言語にも、契約プログラミングという用語こそ使わないものの、似たような仕組みを採用している言語がある。
以下のような条件をプログラム内に記述し、条件が満たされているかどうかを必要なときにチェックするのである。
事前条件
その部分が実行される前に満たされるべき条件。その部分を使う側に課せられる義務である。
事後条件
その部分が実行された後に満たされるべき条件。その部分を提供した側に課せられる義務である。
不変条件
常に満たされているべき条件。事前条件でもあり、事後条件でもある条件とも言える。
そんなことよりユニットテストだ!
契約プログラミングのための条件チェック用のコードは、最終製品の段階ではコンパイルから除外されて実行されない。パフォーマンスに影響するからだ。
しかし、どうせ製品に組み込まれないのだったら、ユニットテストに書いてしまえば...おや、誰か来たようだ。
関連項目
- 0
- 0pt