これまでの第十章
表明
どうしても副作用のある操作
副作用のない関数を値オブジェクトに実装することで、いつの間にか状態が変わってしまうような実装を防ぐことができました。
ただ、どうしても副作用が出る箇所、状態が変わるものはどこかで使わざるを得ない箇所がでてきます。それが、Entityですね。
状態が変わらないシステムなんてそうそうないですから、仕方がないですよね。
表明
副作用がEntityで出てしまうのは仕方がない。なので、できるだけ影響を減らそうというのが表明を使う目的ですかね。
いわゆる、保証されるメソッドの結果を記述する「事後条件」と、事後条件が成り立つことを保証するために満たすべき条件を記述する「事前条件」を使うことで、副作用は出るが、予測可能なメソッドにしましょうということですね。
あまり使わない？
ただ、表明が使える言語は少ないですよね。書籍でも表明を使った例すら上げられていない・・・。
javaには表明の機能がありますが、コンパイルオプションを指定しないと使えない・・・。
実際使ったことないなぁ。。。
テストで表明する
代替案としてはテストを書くことが上げられていて、こちらは例も出ていますね。
メソッドが取りうる条件と、テストで実行した結果が合っているかをテストで書いておくことで、それがドキュメントとして利用できるということですね。
Entityのテストとして、事前条件と事後条件を表明するという意図があるということです。
そもそも意図の明白なインターフェースとモデルを頑張る
人は、頭の中に述語を溜め込むだけではない。モデルの概念を推測したり、補ったりするので、アプリケーションの要求を満たすことだけでなく、人にとって意味のあるモデルを見つけ出すことが重要だ。(第三部 第十章より)
元も子もないですが、やはりこれが大前提。ここを頑張ることが重要ですね。