phpmentors-jp
第7章 マルチパラダイム
この章では、問題をいくつかの部分に分割して、その各々を1つのパラダイムで設計することを考えよう。このいわゆる「分割統治」（divide-and-conquer）方式は、マルチパラダイム開発のもっとも単純な形式である。 ― 新装版 マルチパラダイムデザイン p.171
フレームワークとマルチパラダイムデザイン
7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (p.172)
それ以上分割されることのない再利用可能モジュールとして、フレームワークを構築しているという場合を考えてみよう。マルチパラダイムデザインをそのフレームワークに適用して、その結果フレームワーク内部に結合（coupling）を招いてしまったとする。その結合が適切なものであるかどうかは、そのフレームワークを外部から見た場合のコンテキスト、例えばパラメータ化や拡張性において判断される。このときの判断の尺度は、その結合がフレームワークの表現力を拡大し拡張を容易にするかどうかになる。
結合度・凝集度とマルチパラダイムデザイン
7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (p.172)
設計の目標の1つは、部分間の結合度（coupling）を最小化し、かつ各部分内の凝集度（cohesion）を最大化することである。1つのドメインを複数のサブドメインに分割する際、共通性に深い注意を払うことによってこの2つの達成が容易になる。サブドメインはドメインのファミリ構成員をグルーピングすることによって見出だせるが、そのグルーピングは実装技術によって自然に表現できるような共通性に基づいて行うとうまくいく。
具体的な手順
- 簡単な共通性分析から始める。
- それらの共通性が特定のプログラミング言語で表現できるかどうかを確認する。
再帰的に繰り返されるプロセス
7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (pp.172-173)
このようなプロセスは、1度で終了というものではなく、再帰的に繰り返されることもあるだろう。
結合度・凝集度のメリット
7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (p.173)
結合度と凝集度は設計上のあるいはアーキテクチャ上の原則として適用されるものであるが、どちらもコードの質そのものに直接メリットを与えるというよりは、コードを保守する人たちに与えるメリットの方が大きい。結合度を疎に保つという原則は、協同作業するチーム同士や個人同士が独立した作業をするのを容易にする。結合度が高いと、たとえ小規模なチームであったとしても、各プロジェクトメンバがコードを独立に保守するのは困難になり、ひいては設計判断をローカルに行うことができなくなる。これは生産性の低下につながる。
ドメインが組織上の構造に従うことの重要性
7.1 マルチパラダイムデザインの概要 7.1.1 1つのサイズですべてをまかなうことはできない (pp.173-174)
ソフトウェアの疎結合は手段であり、チームの疎結合がその目的である。もしソフトウェアに関することをいっさい抜きにして、政治、文化、政策、歴史といった観点からチームの構造を記述したとすると、ソフトウェアの構造はその組織に従うはずであり、断じてその逆ではない。つまり、最良の（実践的な）ドメインというものは、共通性や可変性の原則に基づくドメイン分析から得られるというよりは、直観に従って動くマーケットやビジネス的な視点から得られるべきものである。したがって、どのような単一のパラダイムも、しっかりとしたドメイン分析により導かれたマルチパラダイムデザインの配置下にあるというのが真だといいうだけでなく、マルチパラダイムデザイン自身は一般常識やビジネスの世界で普及している構造に準ずるべきだというのも真である。そして、いつでもうまくいくような単一のレシピはないのである。
単純に技術的な分析から作られるドメインが優れているというわけではないということだろう。
1つの例として、フォールトトレラントシステムをオーディットする（監査する）というドメインを考えてみよう。…たとえ以上のような論拠が歴史の中で見失われてしまったとしても、プロダクトライン開発において培われて管理されたオーディットの組織（監査チーム）の存在から逆にそうした論拠の妥当性が推論できる。ここからも、技術的な分析結果に過剰な信頼を寄せてそれに従うよりも、組織上の強い伝統に従うことの重要性に気づかせられる。経験上言える大原則として、不完全なソフトウェアの構造に関わっていくことのほうが、組織を変更することに比べれば、よほど容易だということだ。この大原則は、ときとしてドメインの構成を決断する際のガイドとして役に立つ。
7.2 マルチパラダイムデザインのアクティビティ (p.181)
経験を積んだ設計者であれば、そのドメインでの経験から、新しいシステムのアーキテクチャを形作ることができる。高レベルでのシステム構造化は、その大部分が直観に頼ったものだ。最初の切断による「部分」は、独立したビジネス領域になる。その切断部分のそれぞれが固有の歴史的意味と経験に基づくものを内包している（7.1.1項を参照）。
システムの複雑さとドメイン
7.1 マルチパラダイムデザインの概要 7.1.2 複雑さの度合い (pp.175-176)
プロジェクトによっては、あまりにも複雑で一般的な抽象の各技法では歯が立たないものもあるだろう。こうしたプロジェクトが複雑である原因の多くは、単一の階層では表せないことにある。複雑なシステムは、相互に絡み合った複数の階層を伴っている。もしこうしたシステムに対してトップダウン型の技法を用いて抽象を構成しようとすると、たくさんの「トップ」から分析を始めなければならないという状況に陥る。
テレコム系のシステムの例:
- 通話を処理するためのトップ（トップレベルのサブドメイン）
- 課金のためのトップ
- 保守のためのトップ
- オペレーションのためのトップ
- 機能修正追加やシステム管理のためのトップ
- フォールトトレランスのためのトップ
こうした複数のトップの下で、抽象のツリー構造は互いに悪い影響を与える形で干渉し合う。これがシステムというものを複雑にしている理由だ。複雑さは、システムに対する独立した意味のあるビューの数に比例して増大するのだ。
パラダイムの適用ケースとドメイン
7.1 マルチパラダイムデザインの概要 7.1.2 複雑さの度合い (pp.176-178)
- 単一ドメイン、単一パラダイム
- 結合していない複数のサブドメイン、単一パラダイム
- 結合していない複数のサブドメイン、各サブドメインごとに単一のパラダイム
- 結合していない複数のサブドメイン、各サブドメインごとにマルチパラダイム
- 多くのプロジェクトが、このカテゴリに分類される
- 方向付き非循環図（DAG）内の複数のサブドメイン、マルチパラダイム
- 循環を伴うサブドメイン群
マルチパラダイムデザインのビルディングブロック
7.2 マルチパラダイムデザインのアクティビティ (p.180)
- 共通性分析
- 可変性分析
- アプリケーションドメイン分析（問題ドメイン分析）
- ソリューションドメイン分析
設計は分析のアクティビティである
7.2 マルチパラダイムデザインのアクティビティ (p.180)
設計とは、アプリケーション分析結果の構造に、ソリューションドメインの構造を結びつけるアクティビティである。本書では、このアクティビティを変換分析（transformational analysis）と呼ぶことにしよう。これは分析のアクティビティである。すなわち、「構造間の対応づけをする」という分析のアクティビティであり、複数のドメイン間の「変換」を分析対象として扱うのだ。
パターンをドメインとして考えること
7.2 マルチパラダイムデザインのアクティビティ (p.182)
パターンをソリューションドメインの一種で、早期に考慮されるべきドメインであると考えよう。つまり、自分自身でそのドメイン経験を「再発見」するよりも、過去の成功事例に基づいてそれを築きあげた方がよい。
経験・直観に基づく分析
7.2 マルチパラダイムデザインのアクティビティ (p.183)
与えられた問題ドメインに対しては、いくつかのソリューションドメインがそのほかのソリューションドメインよりもうまく適合する。設計チームは、たいていの場合、適切なソリューション技法を選択するのに、これまでの経験に基づくことができる。
これは私たちが実際に日常的に行っていることだと思う。
ソリューション技法すべての分析を試みて、個々のソリューション技法がアプリケーションドメイン分析の結果に適うかどうかを調べたいと考える設計者がいるかもしれない。しかし、そのような盲目的な模索は、コスト的に見て効果的とは言えない。経験に基づくことが可能ならば、そのようにしたほうがよい。
これは、「PHPがJavaのようなものならJavaを使えばいいじゃないか」といった意見に対する答えとなるだろう。
経験に基づくことができない場合には、設計者の直観に基づくのがよい。マルチパラダイムデザインは、そのような直観に対しての「監査」として機能し、設計を正規化するための技法と語彙を提供する。
これも私たちが実際に日常的に行っていることだと思う。
マルチパラダイムデザインが効果的に機能するソリューションドメイン
7.2 マルチパラダイムデザインのアクティビティ (p.183)
マルチパラダイムデザインはあるプログラミング言語に特化したソリューションドメインに対して最も効果的に機能する。というのは、マルチパラダイムデザインが、ある言語機能を使用するかしないかの決定をサポートするからだ。
マルチパラダイムデザインの肝は変換分析
7.2 マルチパラダイムデザインのアクティビティ (p.183)
5. アプリケーションドメイン分析の結果に基づいて、ソリューションドメイン分析を計画する（第7章）
この箇所がマルチパラダイムデザインの肝になる。というのは、この箇所が設計の主要な問題の1つ、すなわち、問題を解決できる実装構造の選択を扱っているからだ。
オブジェクトパラダイムの選択が推奨されるとき
7.2 マルチパラダイムデザインのアクティビティ (p.184)
変換分析の結果、適切なソリューションドメイン技法として、クラスと継承、すなわちオブジェクトパラダイムが支持されることが多い。ここに記述しているよりも完全な形で、オブジェクトパラダイムを利用しているツール、技法、手法は多数ある。主流とも言えるこのような技法を用いるのは賢明である。ただし、マルチパラダイムデザインや経験により、対象としているドメインにその技法が適切であるということがわかっている場合に限って、そのような技法の選択を推奨できるのだ。
ドメイン特化言語の作成を検討する
7.2 マルチパラダイムデザインのアクティビティ (p.184)
アプリケーションドメインに適う実装ドメイン技術を見つけるのが困難なこともある。アプリケーションドメインの共通性と可変性が、これまでに知られているソリューションドメインのいずれにもフィットしないということもある。このような問題に対しては、ソリューションドメイン構造をカスタマイズするというのが最適であるということも多い。すなわち、そのドメインのための新しい言語を作成するのである。そのような言語のことを、「アプリケーション指向言語」（application-oriented language; AOL）と呼ぶ（「アプリケーション固有言語」"application-specific language"とか、「小さい言語」"little languages"と呼ぶこともある[Bentley1988]）。
ここでいうアプリケーション指向言語は現在のドメイン特化言語である。
ドメイン特化言語の利点
7.2 マルチパラダイムデザインのアクティビティ (p.186)
しかし、プログラミングの利便性、静的な解析、形式的な検査、デバッキング、自動ドキュメント生成、最適化というAOLの利点は、開発コストやメンテナンスコストを差し引いても余りあるものだ。
マルチパラダイムデザインを適用した開発プロセス
7.2 マルチパラダイムデザインのアクティビティ (pp.181-186)
- 直観に従って、問題をサブドメインに分割する（4.1.4項）。
- そのドメインでの経験から直観的に
- 固有の歴史的意味と経験に基づくものを内包する
- 未経験のドメインの場合、問題全体を分析する。（ステップ3および第4章を参照）
- そのドメインでの経験から直観的に
- これは以前に経験したことがあるだろうか。
- 既存の設計成果の再利用を検討する。
- アプリケーションのサブドメインを分析する。
- ソリューションドメインを分析する。
- 自分やチームの経験、加えて第三者の経験（パターン）に基づくことができる。
- 経験に基づくことができない場合には設計者の直観に基づくことができる。
- アプリケーションドメイン分析の結果に基づいて、ソリューションドメイン分析を計画する（第7章）
- マルチパラダイムデザインの肝
- アプリケーション指向言語（Application-Oriented Language; AOL）を評価する。
理想的なサブドメイン分割
7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.186)
4.2節で議論したように、アプリケーションドメインを互いに分離されたサブドメインに分割することが重要である。このとき、別のアプリケーションで再利用できるようにサブドメインに分割できれば理想的だと言える。例えば、コンパイラのために書いたシンボルテーブル管理コードは、リンクエディタでも利用できるだろうし、デバッガやそのほかのソフトウェア生成ツールでの利用を考慮に入れて設計することもできるだろう。
これはサブドメイン分割の際に、そのサブドメインに水平的な性格（主たるドメイン以外のドメインでの利用が可能かどうか）を与えられるかどうかを検討する価値があることを示す。例えば、ORMドメインのサブドメインDBAL（Database Abstraction Layer）を、そのORMドメインのみで利用可能として設計するのか、その他のドメインでの利用も考慮に入れて設計するのか。
サブドメイン（分割）の品質向上のための目標
7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.187)
- 理想的には、この分割は本質的で互いに結合していないドメインの切れ目に沿っているのが望ましい。
- ドメインの中には、それ1つだけで十分に高いマーケット性を持つというものもある。このことが、適したドメインであるための（必要条件ではないけれども）十分条件であることも多い。
- ドメインは互いにできるだけオーバーラップしないのがよく、また干渉し合うのもできるだけ避けるのが望ましい。
- 同一の共通性が複数のドメインの中に存在するというのも望ましくない。
ソリューションドメイン上のトレードオフ（フォース）がアプリケーションドメイン分析に影響を与える
7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.189)
このようなアーキテクチャ上のトレードオフが、各サブドメインの共通性分析に影響を与えるのだ。さらに、それを実現するためのサブドメインとモジュールの独立性にも影響を与えることになる。
以下のステートメントがあり、
typedef int Int;
それを処理する以下のような文法を考える。
type_name decl_list;
ステートメントにある型識別子intを最初のフェーズである字句解析で検証（意味解析を伴う）しようとすると字句解析ドメインから意味解析ドメインへの依存が必要になる。
name decl_list;
しかし、この文法ではnameが型識別子であることの検証は意味解析フェーズまで遅延されるため、字句解析ドメインから意味解析ドメインへの依存は不要である。しかし、検証と意味解析の結合度は増すことになる。
"糊づけ"ドメイン
7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.189)
stringのような抽象が収まるようなドメインについて。基本ビルディングブロックドメインがその候補になるだろうが、標準ライブラリやOSのAPIでサポートされる場合も多い。このようなドメインを包含するものは「ツールキット」(tool kit）と呼ばれることがある。[Gamma1995]
ドメイン分析と繰り返し
7.3 例：単純なランゲージトランスレータ 7.3.1 サブドメイン分割 (p.189)
ドメイン分析が終わったならば、設計者は最初の分割の基準が依然適切なものであるかどうかを確認することになる。ドメイン分析の結果、抽象が広げられたり変形させられたりするが、そのことによりドメイン間の結合を変更しなくてはいけない可能性が発生する。このような結合のシフトの結果、サブドメインの境界を変更したほうがよいとわかることもある。その場合には、問題の再分割により、新しい認識に基づくサブドメインを決定すべきだろう（通常は、設計詳細のチューニングを行うことになる）。このプロセスを繰り返して収束させる。
ドメインの抽象の導出に設計者の直観を利用する
7.3 例：単純なランゲージトランスレータ 7.3.2 サブドメインに適用できる正しいパラダイムの見つけ方 (p.191)
ここで注意してほしいのは、ドメインの語彙から直接的に可変性テーブルを作成するのではないことである。ドメインの抽象を導き出すためには、設計者の直観を利用する。この直観をガイドするのに経験則を用いることができ、その経験則に従えば、広範な共通性を基盤とする抽象を探し出す適切な足場を得ることができるだろう。[Weiss+1999]では、設計を3つの観点から見るようにと提言する。以下はその観点の優先順位である。
- ドメインの外部インタフェースにおける抽象
- ドメインにおける仕事の単位（例えば、内的な状態と状態遷移）
- そのほかのすべてのもの
共変とモデルの洗練
7.3 例：単純なランゲージトランスレータ 7.3.2 サブドメインに適用できる正しいパラダイムの見つけ方 (pp.194-195)
このテーブルの2つの列がほとんど同一であることに注意しよう。すなわち、
typedef、識別子、関数などといったシンボルの型によって可変性を表現している2番目の列と、整形アルゴリズムにおける可変性を表現している最後の列である。それぞれの列は別個の可変性範囲を定義している。しかし、これらに対する可変パラメータは、同一の設計変更を引き起こす。すなわち、実行時構造と整形化（formatting）である。このとき、この2つの可変パラメータは共変（covariant）であると言う。 … すなわち、可変パラメータSymbole Table FormattingとLayoutは共変である。2つのパラメータが共変であるとき、その2つの可変パラメータを包含する図の部分の、リーフ（葉）ではないノードを取り除くことができる。
共変である可変パラメータ（またはドメイン）はそれらを包含するリーフノードをエントリポイントとするドメインと見なすことで、依存関係を縮退させることができる。これはモデルの洗練のために役立つだろう。
可変性依存図 共通性ドメイン：Name
縮退した可変性依存図 共通性ドメイン：Name
p.195の図にパッケージ（ドメイン）を加えたもの。
設計の実装
7.3 例：単純なランゲージトランスレータ 7.3.3 設計と実装 (p.197)
この段階で、コードの中から構造を直接的に見つけ出せることも多い。
私の場合、Coplien氏の提唱する設計（7.4節を参照）は多くの場合コーディングを通して行っている。より正確に言えば、粗い設計は直観的または経験的に頭の中にあり、コーディングを通してそれが洗練・修正されるというものである。この点についてはCoplien氏の見通し以上のものがコーディングという活動に含まれていると考えることもできるだろう。
設計されたドメインモデル
7.4 分析ではなく、設計を 7.4.1 分析なのか、アーキテクチャなのか、それとも設計なのか？ (pp.198-199)
マルチパラダイムデザインのアクティビティは、伝統的な概念で言えば、分析、アーキテクチャ、設計のどれに最もあてはまるものなのだろうか。古典的な意味での分析ではないことだけは確かだ。なぜならば、マルチパラダイムデザインではドメインの知識の組織化を行うのであって、その知識を獲得するからではないからだ。構造と分割の基準を考え、そして（構造における）「ハウ（how）」に焦点をあててきたのであるが、それは（振る舞いにおける）「何（what）」を超越するものだ。ここでドメイン知識を組織化するために用いてきた知識は、新しいドメイン知を獲得してそれを組織化する際にも役立つ。語彙をサブセットにクラスタ化することができ、このことからドメイン構造についてのヒントが得られる。しかし、最終的に分割を決定するのが洞察や直観であることには変わりがない。最適な方法は、システムをどのように拡張するかという予見に基づいて分割が行われることだろう。すなわち、優れたアーキテクチャは変更をカプセル化する。そして、何度も繰り返すが、経験と直観が最も優れたガイドとなり得るのだ。歴史が未来を予言するのである。
マルチパラダイムデザインのアクティビティは、設計者が経験と直観をガイドとして変更がカプセル化されたドメインモデル（ドメインの構造、アーキテクチャ）を設計（デザイン）することである。そのようなドメインモデルはドメイン駆動設計でいうところの深いモデルといえるだろう。
Coplien氏のモデル駆動設計
第6章 ソリューションドメイン分析 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン パターンとマルチパラダイムデザイン (p.159)
マルチパラダイムデザインは、アプリケーションドメインとソリューションドメインを互いに織り合わせて、1つの構造に収束させる。この構造は、それぞれのドメインのフォースを調和させたものである。
7.4 分析ではなく、設計を 7.4.1 分析なのか、アーキテクチャなのか、それとも設計なのか？ (p.199)
アーキテクチャの最初のレベルがアプリケーションドメイン基準に従う粗い分割であるならば、アーキテクチャの第2レベルで、ソリューションドメインの構造で支援される抽象が生成される。ここでソリューションドメインの構造と言っているのは、プログラミング言語により支援されるもののことである。これは突然の転換のように見えるかもしれない。しかし、このことが必然であること、そして、この突然に見える転換のほうが、漠然とそうかもしれないと想定していたものよりもストレートな変換であるというのは、筆者の信念である。C++を使用すれば自分たちで抽象を作成することができる。抽象の上に抽象を構築することによって、多くの場合、表現力のレベルをドメイン語彙と同一の平面上に向上させることができる。その意味で、C++はドメイン語彙を表現し構造化するための最適な道具である（ただし、それは最も基底的なレベルの表現になるだろう）。
これまで、いろいろな形で表現されてきたCoplien流の（ドメイン駆動設計の）モデル駆動設計ともいえるものが、ここではよりはっきりと表現されている。これは私の感覚を支持してくれるものである。
プログラミング言語は初期設計における関心である
マルチパラダイムデザインを使用すれば言語が支援する要素に従ってアーキテクチャの形を決めることができるけれども、それらが低レベルの技法だとか、バックエンドの技法であると言っているのではない。言語の考察と関心は、設計の最も早い段階でなされる考察に影響を与える。つまり、プログラミング言語はバックエンドや実装の関心というより、初期設計における関心なのだ。しかし、だからと言って、言語には高レベルの抽象が欠けているという意味ではない。
ソリューションドメインの構造がアプリケーションドメインの構造に影響を与える
7.5 例：自動微分 (pp.201-202)
-
ここに挙げたアプローチのいずれを選択するかによって、異なる設計をすることになるという事実は注目に値する。異なる設計ではあっても、同じ問題に対する解決策であることには違いがない。この例から、問題の構造だけからでは設計の構造は明白にならないということがわかるだろう。解決策の構造は、解決策の技法といった実現のための戦略がどのようなものであるかを理解してはじめて出現するものなのである。
-
しかし、設計上のある選択が問題の構造を自由に変えてしまうとしたら、それは問題の一部であると見なすべきだろう。
-
解決策上の選択を記述することにより、要件を適切に表現できるという例は多数ある。集中処理と分散処理の選択、実装言語の選択、オペレーティングシステムやスケジュール管理の選択などを、この例として挙げることができるだろう。
-
ほかの手法とは異なり、マルチパラダイムデザインではこの点を重要だと見なし、解決策上の選択を問題に加えるというスタンスを設計に持ち込むことを推奨している。
7.5 例：自動微分 7.5.3 値ドメイン (p.204)
自動微分という解決策を選択しないとなれば、分析のトップレベルのドメインから異なったものになるだろう。サブドメインも、ニュートンメソッドと自動微分では異なるものになる。形式微分（symbolic differentiation）をサポートするような解構造というものも考えられるだろう。ソリューション技術の選択により、ドメイン分析が変わるのである。これこそが、繰り返し開発が実施されなくてはいけない根拠になる。そしてこのことは、新しいドメインに対しては特に重要である。
モデルのスパイラルアップ
7.5 例：自動微分 7.5.3 値ドメイン (p.207)
ここで挙げた設計はオブジェクト指向ではない。この問題の重要な抽象を捉える多重定義のように、マルチパラダイムデザインが適切なソリューションの技法を特定を助けたのである。このような「問題」の抽象の多くはソリューションの構造を規定する力を持つ。（拙訳） すなわち自動微分にも、ニュートン法にも、手動方式にも適っていると言えるようなソリューションの構造を見つけ出すことは困難である。 This design isn't object-oriented. Multi-paradigm design helped identify appropriate solution techniques such as overloading that capture important abstractions of the problem. Many of these "problem" abstractions foresee the solution structure. That is, it would be difficult to find a single solution structure well-suited to automatic differentiation, Newton's method, and manual techniques.
ここでいう「問題」の抽象は、以下のように、マルチパラダイムデザインによって「解決策上の選択を問題に加え」られた結果であって、はじめから存在するものではない。
元の問題: 「これまで考えられてきた設計やプログラミングの便法を可能なかぎり利用して、複雑な関数の導関数を計算する。」
変更された問題: 「自動微分を使用して、複合関数の導関数を計算する」
このような手法は現実世界で頻繁に使われているものだと考える。
再利用・拡張しやすい設計を
7.5 例：自動微分 7.5.4 設計の拡張 (p.208)
ドメイン分析の最も重要なゴールは、再利用と拡張に対するコストを最低限に抑えることである。優れた設計であれば、最初の段階から拡張を考慮に入れている。優れた構造であれば、変更を望ましい形で取り込むことができる。そのような構造においては、可変パラメータにより変更可能な箇所が表されているのである。
「再利用と拡張に対するコストを最低限に抑える」ために、「最初の段階から拡張を考慮に入れ」た設計を行うことがドメイン分析の要諦である。
再利用の2つのレベル
7.5 例：自動微分 7.5.4 設計の拡張 (p.208)
- フレームワークの再利用
- フレームワークの既存のコードに変更を加えずに、可変パラメータの値を変えることによって利用する。
- フレームワーク自身の変更時の再利用
- フレームワークに新しい機能を追加する場合も、再利用できるように設計する。