契る意味@KYON_MM

- PYKONJP2014 - 2014/05/31

TABLE OF CONTENTSおめでとうございます自己紹介

本題

まとめとか補足とか

1 おめでとうございますtk0miyaさん、tmmkrさんご結婚おめでとうございます。

二人のこれからにたくさんの幸せがありますように。

2 自己紹介はじめまして！きょん(@kyon_mm) 26歳 名古屋で働いています。先日 kaori_t_spicaと結婚しました。かわいいです。Groovy, F#, C#, ScalaSCMBootCamp, Nagoya.Testing, TDDBootCampF# TypeScript Vue.js のお仕事をやろうとしているところ。

3 本題

3.1 結婚されたということで婚姻たくさんの約束家族としてつくりなおすものたくさんの契りをすると思います。

3.2 ということで今日は契約プログラミングの話をします。Design by Contract契約による設計たのしー！

3.3 なぜ契約するのか我々の世界は結局相手とどうやって協調して生活するかです。 相手を信用するにしても、どういうお願いをすればどう

いう結果になるのかの保証が必要になります。

3.4 DESIGN BY CONTRACT事前条件

事後条件

不変条件

あるオブジェクトのpublicなメソッドは開始前に必ず事前条件を満たしている必要があるあるオブジェクトのpublicなメソッドは終了後に必ず事後条件を満たしている必要があるあるオブジェクトが生成されたタイミング、publicなメソッドの呼び出し前後に必ず不変条件を満たしている必要がある

0

3.4.1 イメージclass Sample{

List<Item> items = new List<Item>();

boolean invariant(){ // 不変条件 assert items != null } Sample(){ invariant()　// 不変条件 }

List<Item> add(item){ assert item != null　// 事前条件 invariant() // 不変条件 items += item assert items.count == old items.count + 1 // 事後条件 invariant() // 不変条件 }}

3.5 メリット

3.5.1 エラーから何が悪いのかわかる。

事前条件エラー : 使う側のバグ事後条件エラー : 使われる側のバグ不変条件エラー : 使われる側のバグ

3.5.2 防御的プログラミングとは幾分異なる

モジュール設計は次のように分類することが出来る。

要求型 : 契約プログラミング -> これを満たせばいいよ！保護型 : 防御的プログラミング -> よくわからないときにはなんとかします！なんとかってなんだよ！！！っていうことで出来るだけ契約プログラミングのようなスタイルでプログラミングするほうがいいです。

3.5.3 テストでは漏れがちなものをカバーする

あなたのテストコードは入力の範囲は記述されているか？あなたのテストコードは出力の範囲は記述されているか？それ契約プログラミングなら普通です。

3.6 HOOREもう少し言うとプログラムがホーアの論理を満たすようにな

んとか頑張れないか挑戦する感じ。

{P} C {Q}P = 事前条件、C = プログラム、 Q = 事後条件Pという条件でCを動作させるとQになる。まともにやるとプログラムの停止性を証明することになるので結構つらい。言い換えると、Pが与えられた時には必ずQに至ることを示す必要がある。そういうのはCoqやAgdaに任せましょう。ホーアの論理の実現としてUPPAALがあります。π計算勉強しましょう。並列並行基礎勉強会で@keigoiが話してくれました。

3.7 契約プログラミングによる設計クラスAのメソッドFooはP1を満たすときQ1を返す。クラスBのメソッドBarはP2を満たすときQ2を返す。Fooの引数にBarの結果を渡すとき、Q2∈P1 である必要がある。DbCは型レベルプログラミングが難しい君たちの味方である。

3.8 ABSTRACT DATA TYPE(抽象データ型)契約による設計をすることでそのクラスが抽象データ型を実

装をしていることを表現できている。

抽象データ型の処理事前条件 -> 契約プログラミングの事前条件,不変条件抽象データ型の公理 -> 契約プログラミングの事後条件,不変条件

いくつかの契約プログラミングの不変条件は実装依存として存在することがある。

3.8.1 EX.) STACK ADTのPRECONDITIONS

remove(s:STACK[G]) require not empty(s)item(s:STACK[G]) require not empty(s)

3.8.2 EX.) STACK ADTのAXIMOS

item(put(s, x)) = xremove(put(s, x)) = xempty(new)not empty(put(s, x))

4 まとめとか補足とか契約は合意の元に行われるので安全になる。OOPでは実装依存が強いのでテストコードと変わらないかもしれない。(oldとか)FPでは比較的やりやすい(oldとか)大抵の言語はライブラリ提供で実行時検査になっている。ループを使うときは必ずループ不変表明をしましょう。ループとか正直証明がないと使うの怖いです。オブジェクト指向入門、Touch Of Class次は運算、ホーア論理、π計算あとは　なごや　に来ればだいたいok