Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

契る意味 #pykonjp2014

1,239 views

Published on

Py婚JP 2014でLTしました。
http://connpass.com/event/5426/

Published in: Technology
  • Be the first to comment

契る意味 #pykonjp2014

  1. 1. 契る意味@KYON_MM - PYKONJP2014 - 2014/05/31
  2. 2. TABLE OF CONTENTS おめでとうございます 自己紹介 本題 まとめとか補足とか
  3. 3. 1 おめでとうございますtk0miyaさん、tmmkrさんご結婚おめでとうございます。 二人のこれからにたくさんの幸せがありますように。
  4. 4. 2 自己紹介はじめまして! きょん(@kyon_mm) 26歳名古屋で働いています。 先日kaori_t_spicaと結婚しました。かわいいです。 Groovy, F#, C#, Scala SCMBootCamp, Nagoya.Testing, TDDBootCamp F# TypeScriptVue.js のお仕事をやろうとしているところ。
  5. 5. 3 本題
  6. 6. 3.1 結婚されたということで 婚姻 たくさんの約束 家族としてつくりなおすもの たくさんの契りをすると思います。
  7. 7. 3.2 ということで 今日は 契約プログラミングの話をします。 Design byContract 契約による設計たのしー!
  8. 8. 3.3 なぜ契約するのか 我々の世界は結局相手とどうやって協調して生活するかで す。 相手を信用するにしても、どういうお願いをすればどう いう結果になるのかの保証が必要になります。
  9. 9. 3.4 DESIGN BY CONTRACT 事前条件 事後条件 不変条件 あるオブジェクトのpublicなメソッドは開始前に必ず事前 条件を満たしている必要がある あるオブジェクトのpublicなメソッドは終了後に必ず事後 条件を満たしている必要がある あるオブジェクトが生成されたタイミング、publicなメソ ッドの呼び出し前後に必ず不変条件を満たしている必要が ある 0
  10. 10. 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() // 不変条件 } }
  11. 11. 3.5 メリット
  12. 12. 3.5.1 エラーから何が悪いのかわかる。 事前条件エラー : 使う側のバグ 事後条件エラー : 使われる側のバグ 不変条件エラー : 使われる側のバグ
  13. 13. 3.5.2 防御的プログラミングとは幾分異なる モジュール設計は次のように分類することが出来る。 要求型: 契約プログラミング-> これを満たせばいいよ! 保護型: 防御的プログラミング-> よくわからないときには なんとかします! なんとかってなんだよ!!! っていうことで出来るだけ契約プログラミングのようなス タイルでプログラミングするほうがいいです。
  14. 14. 3.5.3 テストでは漏れがちなものをカバーする あなたのテストコードは入力の範囲は記述されているか? あなたのテストコードは出力の範囲は記述されているか? それ契約プログラミングなら普通です。
  15. 15. 3.6 HOORE もう少し言うとプログラムがホーアの論理を満たすようにな んとか頑張れないか挑戦する感じ。 {P} C {Q} P = 事前条件、C = プログラム、 Q = 事後条件 Pという条件でCを動作させるとQになる。 まともにやるとプログラムの停止性を証明することになる ので結構つらい。 言い換えると、Pが与えられた時には必ずQに至ることを示 す必要がある。 そういうのはCoqやAgdaに任せましょう。 ホーアの論理の実現としてUPPAALがあります。π計算勉強 しましょう。 並列並行基礎勉強会で@keigoiが話してくれました。
  16. 16. 3.7 契約プログラミングによる設計 クラスAのメソッドFooはP1を満たすときQ1を返す。 クラスBのメソッドBarはP2を満たすときQ2を返す。 Fooの引数にBarの結果を渡すとき、Q2∈P1 である必要が ある。 DbCは型レベルプログラミングが難しい君たちの味方であ る。
  17. 17. 3.8 ABSTRACT DATA TYPE(抽象データ型) 契約による設計をすることでそのクラスが抽象データ型を実 装をしていることを表現できている。 抽象データ型の処理事前条件-> 契約プログラミングの事前 条件,不変条件 抽象データ型の公理-> 契約プログラミングの事後条件,不変 条件 いくつかの契約プログラミングの不変条件は実装依存とし て存在することがある。
  18. 18. 3.8.1 EX.) STACK ADTのPRECONDITIONS remove(s:STACK[G]) require notempty(s) item(s:STACK[G]) require notempty(s)
  19. 19. 3.8.2 EX.) STACK ADTのAXIMOS item(put(s, x)) = x remove(put(s, x)) = x empty(new) notempty(put(s, x))
  20. 20. 4 まとめとか補足とか契約は合意の元に行われるので安全になる。 OOPでは実装依存が強いのでテストコードと変わらないか もしれない。(oldとか) FPでは比較的やりやすい(oldとか) 大抵の言語はライブラリ提供で実行時検査になっている。 ループを使うときは必ずループ不変表明をしましょう。ル ープとか正直証明がないと使うの怖いです。 オブジェクト指向入門、Touch Of Class 次は運算、ホーア論理、π計算 あとは なごや に来ればだいたいok

×