C++のためのAPIデザイン2章(1)
読書メモメモ
２章は長いので複数回に分けます．
2.1 問題ドメインのモデリング
APIは特定の問題解決，タスクの実行のために記述される．そのためにはAPIはその問題の明確なソリューションを提供するべきである．たとえば，問題ドメインの抽象概念化を行いドメインのモデル化を行う．モデルに対して実際の知識や経験が使用することができるため，ユーザフレンドリなAPIとなる．
抽象概念の提供
APIは対象の問題の論理レベルの抽象概念を提供する．つまり，APIが解決するのは概念レベルの課題であり，実装レベルの課題ではない．
APIドキュメントは，テクニカルな知識の無い非プログラマが読んでも理解できるインタフェースの概念と機能が書かれていなければならない．
→APIが提供するのは，実装レベルの課題解決策ではなく，より一般的化された問題の解決策であるから，テクニカルな知識無しでドキュメントは書かれるべき，ということなのだろう(また，そうなっているかどうかの確認方法として，非プログラマに読んでもらう必要がある，と)．
概念化が足りないということは，そのドキュメントを作成された時に解決を目的とした
問題以外を解くことができない(=過度に問題を具体化しすぎ，範囲を狭め過ぎている？)可能性も起こりえる気がする
2.2 実装詳細の隠蔽
APIの利点は，内部詳細を隠すことで後から使用者に影響を与えずにその詳細を変更できること．
→C++の機能的な実装隠蔽方法について書かれていた．
- 宣言と定義による物理的な隠蔽
- 論理的な隠蔽(アクセスレベル(public, private, protected)，カプセル化)
- メンバ変数の隠蔽・クラスの隠蔽
→メンバ変数の隠蔽およびカプセル化は，入力値・出力値の論理的チェックを可能にする点でも有効．
また，相互に影響しあうメンバ変数が互いにユーザから自由に変更が可能(public)にされていた場合，
それらの関係性は即座に破綻するだろうから，そういった場面でも必要な手段だろう．
ちなみに，書籍には遅延評価(setterで値が設定されても，値の出力が必要な場面までは計算を行わない)，
キャッシングなどについても説明されていた．
遅延評価の具体例は，簡単に例をあげればsetterと入力の値の計算がセットになっていた場合(遅延評価無し)
obj.set(a);//setと計算(1) obj.set(b);//setと計算(2) x=obj.get();//出力(3)
のように出力(3)の場面においてobj.set(b)の値が使用されるため，
(1)の計算が無駄になってしまう．
そこで，実際に値の計算が必要な時に行えるようにgetterの方に計算を実装(評価を遅延させる)すれば
obj.set(a);//setのみ obj.set(b);//setのみ x=obj.get();//計算と出力
のように計算回数は無駄なく１回で済む．
という理解でいいよね？
