【契約による設計】あなたのプログラムが守るべき３つの約束

契約による設計。プログラム設計の安全性を高めるための、設計手法です。

あなたが作るクラスやメソッドについて、それを使う人との間に、守るべき事項について契約を交わします。契約を守ることにより、安全に使えるようにします。

「契約による設計」で交わす３つの契約

クラス／メソッドについて交わのは、以下の３つの契約です。

この３つの契約により、クラスやメソッドの誤った利用を防止します。

事前条件－使う側が守る条件

事前条件 (precondition)は、メソッドを使うときに、使う側が守るべき契約です。

簡単に言うと、メソッド実行時に、ありえない条件を入力しない、ということ。

メソッドを呼び出すときの入力値には、特定の前提条件が必要な場合があります。

• この範囲の値しか受け付けられない
• この文字は空であってはいけない

例えば「平方根を求める」メソッドなら、その入力は０以上でなければなりません。（そうでないと計算できませんね）。

事後条件－使われる側が守る条件

事後条件 (postcondition)は、メソッドの結果が返却されたときの契約です。

メソッドが呼び出しが完了したら、呼び出し側が欲しい情報を必ず返すこと。これを約束します。

当然その結果は、呼び出し元の求めるものとなっている必要があります。「平方根を求める」メソッドなら、input=result*result となっていることが、求める結果です。

不変表明－常に守られるべき条件

不変表明 (invariant)は、クラスが常に保っておくべき性質、を約束するものです。

オブジェクトの生成時、メソッドを呼び出す前、呼び出した後。どんな場合においても、クラスがその外部に公開しているすべての操作について、保証されるべき性質です。

例えば、財務合計balanceは、常に内訳entryの金額amountの合計であるべきなので、balance == sum(entries.amount()) は、いつでも成立している必要があります。

契約による設計とは「クラスの説明書」を作る事

契約による設計のメリットとして、一般的に以下のようなものが言われます。

• 仕様の明確化　クラスの振る舞いを明確に規定できる
• エラー早期発見　契約違反のチェックで、エラーを早期に特定できる
• 安全性強化　契約に沿って動作確認することで堅牢性が向上

まとめれば結局のところ、「契約による設計」の根元にあるのは、クラスの「説明書」を作ること。

設計書があれば、それがどのようなクラスなのか、どう使うべきなのか、が明確になります。

さらに、「クラスの説明書」があることにより、

使う側、作る側の双方に、メリットがあるのです。

契約の実装方法は２種類

契約をプログラムで実装すること、それはすなわち、契約が破られないようにする仕掛けを作ることです。

考え方は大きく２つあります。

どちらも有効ですが、特に効くのは２番目です。そもそも契約違反の実装ができないのですからね。

実装方法１：表明（assert）による契約のチェック

まず思いつく実装は、契約が守られているかを、都度のタイミングでチェックすること。

確認には「表明」(assertion)が使われます。

表明（assert）で契約違反をチェックする

表明とは、必ず成立すべき条件式です。falseとなるなら、それは契約違反を意味します。

「平方根を求める」メソッドなら、表明はつぎのとおり。

C,C++,C#,Java,Pythonなど、多くのプログラム言語では、assert と呼ばれる機構が備わっています。

assert input = result * result

ほとんどの場合、assertは、false となった時点で即時にプログラムが停止します。false、つまり契約違反となるのはバグであり、回復不可能だからです。

assertはバグ検出のために使う

上記からも分かるように、assertはバグを検出するためのもの。

通常発生しうる状態（バグでない状態）に、表明(assert)を使ってはいけません。assertは、どのプログラミング言語でも「リリーズ時は無効とする」オプションが備わっています。

実装方法２：型（Type）を使って契約を守らせる

実装方法のもうひとつは、そもそも契約を破るような実装が出来ない仕掛けにすることです。

プログラミングの型定義を駆使して、契約違反なコードが作れないようにします。

不変表明に、不変クラスを導入する

不変表明は、つまるところクラスメンバの状態に依存します。ならば、メンバを絶対更新できないようなクラスなら、必ず不変表明が守られるわけです。

このような、オブジェクト生成時からメンバを変更不可としたクラスを、不変クラス（イミュータブルクラス）といいます。不変クラスにすれば、それでもう不変表明が守られるわけです。

可能な限り、不変クラスでの実現を考えましょう。

事前条件/事後条件を、定められたインタフェースしか取れない型で守る

事前条件や事後条件は、このようなパターンが多いでしょう

• 特定範囲の引数しか入力できない（0以上のみ入力可能、など）
• 特定の状態のときしか約束した結果が返せない（開始状態のときのみ可能、など）

ならば、

• 特定範囲の値した取り得ない「型」を入力とする（PositiveNumber型を入力とする）
• 特定の状態をしめす「型」を分離してメソッドを作る（StandbyProcess型とActiveProcess型を分離する）

といったように、型の定義により契約を表すことで、契約はより頑健なものとなります。

契約による設計は、テストにも役立つ

契約による設計によって設計されたクラスは、ユニットテストによる品質確認も容易となります。

そう「契約が守られているか」をテストで確認すればよいのですから。テストケースも明確になります。テスト駆動開発との相性は抜群です。

契約による設計は、自動ユニットテストで、契約内容を常時確認できることが有効です。あちこちにassertを入れてコードを複雑にするよりも大事です。

まとめ

クラス設計時には、ついつい、その中身をどうするかに心を奪われてしまいがち。そうすると、使う側にとってはいまいち使いにくいクラスができあがります。

「契約による設計」を使うと、クラスを使う側の視点に立った設計ができます。あなたのクラスを強固なものにしましょう。

あわせて読みたい

【コード改善】今日から使えるリファクタリングテクニック12選 リファクタリング。プログラミングにおける、コードの内部構造を改善するプロセスです。 大規模な変更、新機能の追加、そんなときにリファクタリングは効果的です。ただ…

あわせて読みたい

【過信は禁物】テスト駆動開発の実践方法と、メリット３つと注意３つ プログラム開発の中では、あまり派手とはいえない、テスト作業。 欠かすことはできない。けれど、コーディングと比べれば、地味で面白味を感じない… でも、そんなテスト…

あわせて読みたい

【SOLID】依存性逆転原則～大事なのは、抽象にもとづくこと 依存関係逆転原則 Dependency Inversion Principle 上位モジュールは下位モジュールに依存してはならない。両者は抽象に依存すべき。 抽象は詳細に依存してはならない。…