契約による設計事始め

by 男爵

Slide 1

Slide 1 text

契約による設計事始め 2020/02/16 Object-Oriented Conference @dnskimox

Slide 2

Slide 2 text

自己紹介男爵所属：Alp,Inc. / Scalebase（サブスクリプション管理のSaaS）開発言語：Scala、TypeScript 好きな話題：OOP、DDD、開発プロセス Twitter：@dnskimox

Slide 3

Slide 3 text

今日は契約による設計の話をします https://en.wikipedia.org/wiki/Design_by_contract

Slide 4

Slide 4 text

契約による設計事始め ▸ 契約による設計とはなにか？ ▸ 事前条件と事後条件 ▸ クラス不変表明 ▸ 表明と例外の関係 ▸ バリデーションとの違い ▸ 明日から使える実践方法

Slide 5

Slide 5 text

1. 契約による設計とはなにか？どこから来た用語で何を意味するのか？

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

バートランド・メイヤー著『オブジェクト指向入門第二版』開放／閉鎖の原則、コマンドとクエリの分離原則、統一形式アクセスの原則、契約による設計、単一責任選択の原則、etc... https://en.wikipedia.org/wiki/Bertrand_Meyer

Slide 8

Slide 8 text

“ キーコンセプトは契約による設計（Design by Contract)である。クラスと顧客の間の関係は、お互いの権利と義務を表した正式な同意と見なすことができる。すべてのモジュールのそのような要求と責任の詳細な定義があって、はじめて信頼性の高い大規模システムが実現できるのである。

Slide 9

Slide 9 text

顧客モジュールと供給者モジュール ● データを利用 ● サービスを利用要求と責任の詳細な定義 = 契約が必要

Slide 10

Slide 10 text

“ 顧客モジュールと供給者モジュールの間の契約は、一方にとっての利益はもう一方の義務となる。効果的かつ信頼性の高いソフトウェアを作るということは、顧客と供給考の間で適切なコミュニケーションを重ねた末、ベストな妥協案にあたる契約を作成することである。

Slide 11

Slide 11 text

契約の形を表明する道具事前条件、事後条件、クラス不変表明、ループ不変表明、etc...

Slide 12

Slide 12 text

様々な種類の表明事前条件ルーチンを利用する際に求められる要求事後条件ルーチンの終了時に保証される特性クラス不変表明クラスインスタンスを特徴付け、その生存中にずっと保持される特性ループ不変表明説明省略ループ変化表明説明省略 check命令説明省略

Slide 13

Slide 13 text

2. 事前条件と事後条件このエラーを出したのは誰だ！

Slide 14

Slide 14 text

メソッドのコード本体を表明で挟む事前条件コード本体事後条件

Slide 15

Slide 15 text

ScalaのCase classの特徴 ● 基本的に全てのプロパティが不変 ● 全てのプロパティのgetterを持つ ● プロパティの一部を変更したコピーを返すメソッドがある

Slide 16

Slide 16 text

Statsを持つCharacterを作る

Slide 17

Slide 17 text

供給者側の隠された意図 ● 回復するメソッドでHPを減らせてしまう ● ダメージを与えるはずがHPが増えている？クラスの作者の想定と異なる使われ方

Slide 18

Slide 18 text

メソッドに但し書きをつける？

Slide 19

Slide 19 text

メソッドに事前条件を仕込む

Slide 20

Slide 20 text

供給者の意図に反した呼び出しができなくなる

Slide 21

Slide 21 text

供給者の意図に則した呼び出しなのに何かがおかしい？

Slide 22

Slide 22 text

メソッドに事後条件を仕込む

Slide 23

Slide 23 text

事後条件に違反していることが判明！

Slide 24

Slide 24 text

事後条件を守るようにコードを修正

Slide 25

Slide 25 text

“ ルーチンの事前条件と事後条件を定義するということは、とりもなおさず、ルーチンとそれを呼び出すものの間で契約（contract）を結んだということである。

Slide 26

Slide 26 text

事前条件顧客は供給者のメソッドを呼び出す際、事前条件を満たす義務を負う。契約によって生じる義務事後条件供給者は事前条件を満たして呼び出されたメソッドを抜ける際、事後条件を満たす義務を負う。

Slide 27

Slide 27 text

事前条件供給者は想定外の状況でメソッドを呼び出されないことが保証されるという利益を得る。契約によって生じる利益事後条件顧客は事前条件を守ってメソッドを呼び出す限り、結果が定義された特性を満たすという利益を得る。どちらのモジュールも想定すべき事項が減る

Slide 28

Slide 28 text

コードがシンプルになる起こり得ない分岐を書かなくて良い、デッドコードの抑制、「但し書き」のコメント不要、etc...

Slide 29

Slide 29 text

責任の所在が明らかに事前条件違反なら顧客側が悪い、事後条件違反なら供給者側が悪い。修正すべきコードは明白。

Slide 30

Slide 30 text

3. クラス不変表明オブジェクトにとって正しい状態とはなにか？

Slide 31

Slide 31 text

“ 事前条件と事後条件は個々のルーチンの特性を記述する。このほかに、全てのルーチンで維持されなければならない、クラスに共通する全体的な特性を表す必要がある。

Slide 32

Slide 32 text

Statsクラスにクラス不変表明を記述する ● インスタンス化の際にチェックされる ● copyの呼び出し時にも毎回チェックされる ● オブジェクトの生成から破棄まで守られ続ける

Slide 33

Slide 33 text

表明違反は即刻エラーになる Diagram featured by http://slidemodel.com

Slide 34

Slide 34 text

クラス不変表明（不変条件）あるクラスのオブジェクトは、生成されてから破棄されるまでクラス不変表明を満たし続ける義務を負う。契約によって生じる義務

Slide 35

Slide 35 text

クラス不変表明（不変条件）コードベース全体において、あるクラスのオブジェクトがクラス不変表明に違反するという想定をしなくて良くなるという利益を得る。契約によって生じる利益

Slide 36

Slide 36 text

コードがシンプルになる起こり得ない分岐を書かなくて良い、デッドコードの抑制、「但し書き」のコメント不要、etc...

Slide 37

Slide 37 text

責任の所在が明らかにクラス不変表明違反はクラス内部のコードに問題がある。事前条件かメソッドの本体を見直すべし。

Slide 38

Slide 38 text

4. 表明と例外の関係契約による設計なら例外は必要なくなる？

Slide 39

Slide 39 text

事前条件供給者は想定外の状況でメソッドを呼び出されないことが保証されるという利益を得る。契約によって生じる利益事後条件顧客は事前条件を守ってメソッドを呼び出す限り、結果が定義された特性を満たすという利益を得る。事後条件を守ることを常に保証できるか？

Slide 40

Slide 40 text

コードの正しさだけでは抑制できない実行時エラーファイルアクセスエラー存在しないパス、パーミッションの不一致、ディスクの物理的な呼称メモリエラーメモリ割り当ての失敗、メモリの物理的な故障 OSからのシグナル入力デバイスからの割り込み、中断命令、Kill データベースエラー接続失敗、コネクション数の超過、ロック待ち時間の超過、SQLのシンタックスエラーネットワークエラーコネクション確立の失敗、コネクションの中断外部サービスのエラー認証失敗、外部サービス側のバリデーション、メンテナンス

Slide 41

Slide 41 text

“ ルーチンが契約を満たす状態で実行を終えた場合、そのルーチンコールは成功である。成功しなければ失敗である。（中略）何らかの特別なイベントがルーチンの実行を中断させたときルーチンは失敗する。そのようなイベントを「例外」という。

Slide 42

Slide 42 text

例外は契約の放棄を表すデータベースエラー、ファイルへのアクセスエラー、メモリ確保の失敗、etc...

Slide 43

Slide 43 text

5. バリデーションとの違い要するに入力チェックでは？

Slide 44

Slide 44 text

バリデーションはシステム境界の外からの入力を検証する仕組み

Slide 45

Slide 45 text

表明はシステム境界内のモジュール同士のやり取りを定めた規約常に真

Slide 46

Slide 46 text

外からのいかなる入力に対しても表明違反を起こさないようプログラミングする常に真

Slide 47

Slide 47 text

表明とバリデーションは根本的に異なる道具であるバリデーション表明誰のためのもの？システムを使う人コードを書く人違反が起きた時、どうする？入力内容を改めるコードを修正する本番稼働時に必要？必要必ずしも必要ではない

Slide 48

Slide 48 text

表明は動くドキュメントコードの書き手の想定、クラスの責務の範囲、オブジェクトの「正しい状態」の定義

Slide 49

Slide 49 text

5. 明日からできる実践方法で、結局何から始めればいいの？

Slide 50

Slide 50 text

使っている言語の表明機構を調べる事前条件事後条件クラス不変表明 Scala require ensuring assert PHP assert assert × Ruby raise if/unless raise if/unless × なければ表明を組み込むライブラリを探す

Slide 51

Slide 51 text

事前条件を書くシグネチャで表現しきれない引数の制約はなにか？バグを修正する発生からの経過時間が短いほど原因調査は簡単表明違反を通知する開発環境や本番環境からプログラマへのアラート

Slide 52

Slide 52 text

表明違反は例外なくバグオブジェクトの状態が異常、バリデーションの不足、事前条件が強すぎる、etc...

Slide 53

Slide 53 text

表明違反の修正は簡単問題のコードのすぐ近くでエラーが起きる、データが破損する前に処理が停止する、責任の所在が明白

Slide 54

Slide 54 text

表明を使ってシンプルで正しいコードを！ご清聴ありがとうございました You can find me at @dnskimox & https://dnskimox.hateblo.jp/

Slide 55

Slide 55 text

参考文献 ▸ オブジェクト指向入門第二版概念・コンセプト ▹ 11章契約による設計：信頼性の高いソフトウェアを構築する ▹ 12章契約が破られるとき：例外処理 ▸ https://en.wikipedia.org/wiki/Design_by_contract ▸ https://speakerdeck.com/twada/php-conference-2016-revised ▸ https://qiita.com/kawachi/items/c3cf53e0602fb53e78e9 ▸ https://stackoverflow.com/questions/147969/is-it-idiomatic-ruby-to-add-an-asse rt-method-to-rubys-kernel-class