C++のためのAPIデザイン 3.4〜4章

C++のためのAPIデザイン

3.4 APIのラッピングパターン

GOFを読んでると新鮮味がないな。

3.4.1 プロキシパターン

あるクラスと同じインターフェイスを維持したクラスを間に挟んで動作を修正する。

必ずオリジナルから継承してProxyクラスを実装するものだと思ってたが、全く別クラスでもありなのか。

3.4.2 アダプターパターン

あるインターフェイスを、異なるインターフェイスに変換。

3.4.3 ファサードパターン

サブシステムを使いやすくするために、シンプルなインターフェイスを提供するラッパークラス。

3.5 オブザーバーパターン

MVCとObserverパターンの説明。

パターン名くらい英語のままでいいのに、なぜカタカナにしたがるんだ。

第4章 デザイン

4.1 優れた設計の必要性

技術的負債の話。

4.2 機能要件の収集

APIの機能を明確しろよという話。

4.3 ユースケースの作成

APIをユーザ視点で記述。

4.4 API設計の構成要素

API設計には、アーキテクチャの設計と詳細の設計がある。

4.5 アーキテクチャの設計

システム全体のおおざっぱな構造を決める。
トップレベルのオブジェクトの集合とオブジェクト間の関係。

4.6 クラスの設計

機能の80%を決める、20%のクラスを設計する。

継承の階層を深くしない、リスコフの置換原則を守る、クラス名は大事。

4.7 関数の設計

パラメータを小さく。エラーは十分にドキュメント化。

---

C++の本を以下の２種類に分類するとしたら、この本は２だな。

1. テクニックを駆使するとこんなことができるよ。これで○○のような機能も実現できるよ。
2. 現場では凝ったテクニックを使ってはならない。なぜなら✕✕という問題が起きるかも知れないから。