C++のためのAPIデザイン1章(2)

昨日の続き．

【APIの必要性】
ソフトウェアプロジェクトにAPIを使うべきかどうかは次の２点を検討する
(1)自分でAPIを設計し，記述するべきかどうか
(2)自分のアプリケーションに他人のAPIを使うべきかどうか

APIを作成することの利点として"コードの堅牢性"が向上することがあげられる．利点は以下のとおり．
・実装の隠蔽
モジュールの実装の詳細を隠せば，将来，ユーザを混乱させることなく実装を変更できる．隠蔽がない場合，のデメリットは昨日あげた通り，APIの更新に苦労したり，APIの利用者側のコードの変更が必要になってしまう．

・長寿化
実装を詳細に開示したシステムは，時間が立つに連れ，システム内部の詳細と密結合するコードになりやすく，修正が難しくなる．
優れたAPI設計に投資を行って，その後は一貫したデザインをキープするように徐々に保守をしていけば，コストも抑えられ，ソフトウェアの長寿化につながる
→実装が隠蔽されたAPIを利用する/APIとして機能を切り離すことで，システムとは(少なくともAPI以下のレベルで)疎結合にできる．結果として保守へのコストが下がる，という理解で良いのかな？

・モジュール化の促進
APIは，特定のタスクやユースケースの達成のために作成されるため，結果として特定の分野に特化して機能がモジュールとして作成することができる．
APIの上集合上にアプリケーションを作成すると，内部のモジュールが別のモジュールと依存することが少なくなり，疎結合となる．

・コードの重複の削除
APIを使用することで，コードの重複を減らせる．また，更新の際もAPIを１箇所変更するだけで対応可能となる．
→重複する機能を見つけた場合，API化を検討してみると良いかもしれない

・ハードコードされた値を取り除く
→容易に想像がつく

・実装が隠蔽されているため，最適化・更新・リファクタリングが容易になる

【APIを使用するべきではない場合】
[自分でAPIを書く場合]
他の開発者が使用することを想定した強力で安定したインタフェースを作成する必要があり，品質・設計・ドキュメント・テスト・サポートなどのレベルの高い保守が必要となる．
→多くのソフトから利用されるようになればなるほどAPIの保守は大変そうだ．APIの設計をきちんとしておかなければ，このコストが大きくなりそう．

[サードパーティのAPIを利用する場合]
・ライセンスの制約
GPLなどの感染性のあるライセンスは，商用アプリケーションやソースを公開したくないプロジェクトでは使用できない．

・機能がかみあわない

・ソースコードの欠落
APIにバグがあった場合でも，ソースコードを追うことでその回避策が見つかる可能性があるが，ソースコードが公開されていないAPIではそれを行うことができない．
→ソフトウェア開発において，潜在的なバグを含んだ状態で開発をすすめるリスクを追う．コードの"隠蔽"と"欠落"では大きく異るね

・ドキュメントの欠落
→ソースコードの欠落と同様に，動作の制限事項などについてドキュメントがまとめられていない場合，ソフトウェア開発では不適切な場合がある

この章の残りはAPIの実例紹介など．