【POP88】契約による設計

はじめに

この記事は「プリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則」を読んだ際に記した議事録です。

著作権の関係により、詳細には書きません。詳しい詳細を知りたい方はぜひ本書を読んでみてください。

プリンシプルオブプログラミングをPOPと訳します。

What : 「呼び出し側」と「呼び出される側」の取り決め

関数は「何かしらの作業を行うもの」です。「何かしら」を行う前にその世界の状態について何かしらの「想定」をおき、終了時にその世界の状態について何かの「確約」を得ることができると思います。

「想定」が事前条件であり、関数を呼び出す側が守らないといけない契約となります。「確約」が事後条件となり、関数が守らないといけない契約となります。

このようにお互いに関数側と呼び出す側に条件を作り、「契約」させてプログラミングをすることを「契約による設計」と言います。例えば、呼び出し側では必ず引数を与えたり、関数側では返り値を与えたりと言った責任です。

契約が守れなかった場合は例外の送出や、ソフトウェアの終了といった処置を行います。

Why : 「思い違い」の早期発見

双方の契約を確実に守ことにより、以下のようなメリットを享受することができます。

• 「要求された以上のこともしない、要求されたこと以下もしない」正しいコードであることが保証できる。
• 事前条件が満たされているとして、関数の処理コードを書くことができるのでコードをシンプルに書くことができる。
• 契約を満たさなかった際（問題発生時点で）に、見逃さずにクラッシュさせることで問題の早期発見につながります。

How :コメントとアサーションで契約しよう

契約内容をあらかじめ、関数のコメントで伝えましょう。

そして、契約履行チェックのためのコードは、アサーション（表明）で表現します。契約不履行の場合はソフトウェアが停止するように設計しましょう。

注意点

• 関数側で引数の調整をしない

関数側で渡された引数の調整をしません。返り値の調整はしても、関数側で渡された引数が契約に合うように調整してはいけません。

• 関数側のアサーションを、ユーザーの入力チェックに使用しない

ユーザーの入力内容を関数でチェックしてはいけません。「関数」と「ユーザー入力」の契約ではないので混同させてはいけません。ユーザーの入力チェックは関数を呼び出す前に「引数の妥当性の検証」を行いましょう。

• 関数側では「想定は厳格に」「確約は寛容に」する

なんでも受け付けて（事前条件を緩く）、いかなる時でも正しい結果を返すプログラムは膨大な量になります。そうならないために、処理を開始する前に「受けつける想定（事前条件）を厳格」にして、結果を返す際は可能な限り「確約（事後条件）を少なく」しましょう。

関連 : トラッシュ ＜ クラッシュ

トラッシュ : 問題発生時も実行を継続

クラッシュ : 問題発生時に即座に実行を停止

トラッシュさせてしまうと、無茶苦茶な状態になってしまいます。怪我をした体で運動をするようなものです。プログラムにおいても問題が発生したまま、実行を継続して誤ったデータをデータベースに格納してしまうと取り返しのつかないことになります。

そのようなリスクを考慮し、問題発生時には実行を停止（クラッシュ）させましょう。その方が害が少なくすみます。

終わりに

この記事ではプリンシプルオブプログラミング 3年目までに身につけたい一生役立つ101の原理原則の議事録を自分用に記しています。

この記事ではカバーしきれていない部分も多いので、是非本書を手にとって読んでみてください。

次回、「【POP89】防御的プログラミング 」です。ぜひ、次の記事も読んでみてください。