Scalaで始める表明プログラミング

by 男爵

Slide 1

Slide 1 text

Scalaで始める表明プログラミング 2022/03/04 SaaSプロダクト開発のScala活用事例 @dnskimox

Slide 2

Slide 2 text

自己紹介男爵所属：Alp, Inc. / Scalebase 開発言語：Scala、Apex/LWC（Salesfore）好きな話題：OOP、DDD、アジャイル開発 Twitter：@dnskimox

Slide 3

Slide 3 text

Scalaで始める表明プログラミング ▸ 契約による設計と表明 ▸ 事前条件と事後条件 ▸ 不変条件の実装方法 ▸ Eitherと組み合わせる ▸ まとめ

Slide 4

Slide 4 text

1. 契約による設計と表明

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

顧客モジュールと供給者モジュール ● データを利用 ● サービスを利用お互いの権利と義務を表した正式な同意 = 契約

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

意図明白なインターフェースのこと？

Slide 11

Slide 11 text

それもある。が、それだけではない

Slide 12

Slide 12 text

“ 我々に必要なのは、内部を徹底的に調べなくても、設計要素の意味と操作の実行結果を理解できるようにする方法である。（中略）「契約による設計」学派は次の段階に進み、クラスとメソッドについて、開発者によって保証される「表明」を作成する。『エリック・エヴァンスのドメイン駆動設計』

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

2. 事前条件と事後条件

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

BankAccount（銀行口座）

Slide 17

Slide 17 text

deposit（預け入れ）を実装

Slide 18

Slide 18 text

withdraw（引き出し）を実装

Slide 19

Slide 19 text

顧客側のメソッド呼び出し

Slide 20

Slide 20 text

供給者側の隠された意図 ● 預け入れで残高を減らせてしまう ● 「0円を引き出す」という操作ができてしまうクラス設計者の想定と異なる使われ方をしている

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

供給者の意図に則した呼び出しなのに何かがおかしい？口座残高がマイナスに。それをクラス設計者は想定しているのか？

Slide 26

Slide 26 text

メソッドに事後条件を仕込む ensuring: 確実にする、保証する、確保する

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

“ ルーチンの事前条件と事後条件を定義するということは、とりもなおさず、ルーチンとそれを呼び出すものの間で契約（contract）を結んだということである。『オブジェクト指向入門第2版原則・コンセプト』

Slide 30

Slide 30 text

Slide 31

Slide 31 text

義務顧客は供給者のメソッドを正当な方法で呼び出さなければならない。事前条件によって生じる契約利益供給者はメソッドが呼び出された際、特定の仮説が満たされると保証される。

Slide 32

Slide 32 text

義務供給者はメソッドを抜ける際、定義された状態を満たしていなければならない。事後条件によって生じる契約利益顧客はメソッドの呼び出し後に、特定の性質が得られることを保証される。どちらのモジュールも想定すべきパターンが減る

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

3. 不変条件の実装方法

Slide 36

Slide 36 text

“ 事前条件と事後条件は個々のルーチンの特性を記述する。このほかに、全てのルーチンで維持されなければならない、クラスに共通する全体的な特性を表す必要がある。『オブジェクト指向入門第2版原則・コンセプト』不変条件（クラス不変表明）

Slide 37

Slide 37 text

“ クラス不変条件は、あらゆる操作が終わった時のオブジェクトの状態に関する表明となる。不変条件は、集約全体に対しても宣言することができ、整合性に関するルールを厳密に定義する。『エリック・エヴァンスのドメイン駆動設計』

Slide 38

Slide 38 text

Scalaには不変条件を定義する構文がない

Slide 39

Slide 39 text

ScalaにはCase Classがある

Slide 40

Slide 40 text

BankAccountクラスに不変条件を記述する ● インスタンス化の際にチェックされる ● copyの呼び出し時に毎回チェックされる ● オブジェクトの生成から破棄まで守られ続ける＊ただしイミュータブルな場合に限る

Slide 41

Slide 41 text

不変条件違反は即座にエラーになる

Slide 42

Slide 42 text

義務全てのクラスのオブジェクトは、生成されてから破棄されるまで不変条件を満たし続けなければならない。不変条件によって生じる契約利益コードベース全体において、いかなるときもオブジェクトが定義された性質を満たしていると保証される。

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

ところで、表明エラーは副作用なのでは？

Slide 46

Slide 46 text

“ もう一つのよくある誤解は、表明を制御構造（すなわち、特殊なケースを取り扱う技術）と考えることである。（中略）sqrtが事前条件を持つ場合、x < 0での呼び出しは特殊なケースではない。単純明快、それはバグである。『オブジェクト指向入門第2版原則・コンセプト』

Slide 47

Slide 47 text

表明エラーが起きたらコードを修正すべしオブジェクトの状態が異常、バリデーションの不足、事前条件が強すぎる、etc...

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

副作用の局所化とは分けて考えよう

Slide 50

Slide 50 text

4. Eitherと組み合わせる

Slide 51

Slide 51 text

義務供給者はメソッドを抜ける際、定義された状態を満たしていなければならない。事後条件によって生じる契約利益顧客はメソッドの呼び出し後に、特定の性質が得られることを保証される。事後条件を守ることを常に保証できるか？

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

“ ルーチンが契約を満たす状態で実行を終えた場合、そのルーチンコールは成功である。成功しなければ失敗である。（中略）何らかの特別なイベントがルーチンの実行を中断させたときルーチンは失敗する。そのようなイベントを「例外」という。『オブジェクト指向入門第2版原則・コンセプト』

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

Eitherを使って契約の履行失敗を表すパターン

Slide 56

Slide 56 text

バリデーションとは何が違うの？

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

BankAccountオブジェクトを作る際のバリデーション

Slide 62

Slide 62 text

5. まとめ

Slide 63

Slide 63 text

表明を使ってモジュール間の契約を定義する表明エラーが起きたときはコードを修正する不変条件でデータの破損を未然に防ぐ

Slide 64

Slide 64 text

表明を使ってシンプルで堅牢なコードを書こう！ご清聴ありがとうございました You can ﬁnd me at @dnskimox & https://dnskimox.hateblo.jp/ 👦👧👨👶 😸

Slide 65

Slide 65 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