Atsuhiro Kubo

# 共通性分析と可変性分析の成果物 ``` 3.1 可変性：生の芳香 (p.73) ``` > ドメインエンジニアリングは共通性分析と可変性分析を支援する。そしてその際に、共通性、可変性、バインディング時期、デフォルト、ドメイン関係を把握するための記法を利用する。共通性分析と可変性分析の成果物は、その記法で表現された成果の集合に成る。可変性分析を終えた段階で、多くの場合、これらの成果物を下位レベルの設計（クラスと関数プロトタイプを書くこと）への直接の入力とすることができる。 具体例は`第9章 共依存ドメイン 9.3 例：状態遷移マシン pp.252-259`を参照のこと。

# 正の可変性 ``` 3.3 正の可変性と負の可変性 3.3.1 正の可変性 (p.74) ``` > メッセージサイズとヘッダフィールドの内容に関する可変性は、メッセージをメッセージたらしめる共通性からは独立している。メッセージは、ヘッダに空のフィールドがあろうとも、依然としてメッセージである。1バイトの本体を持っていようと、256バイトの本体を有していようと、1個のメッセージとして、自由に活動することができる。しかし、ヘッダフィールドのフォーマットとメッセージ本体のサイズは、重要な可変性になる。このような可変性は、その基となる共通性のモデルに影響を与えないので、メッセージにそれ自体の定義を洗練させるような何かを「追加する」ことになる。著者は、これを**正の可変性**（positive variability）と呼んでいる。この可変性のために、メッセージをメッセージたらしめるベース仕様に対して項目が追加されることになるが、そのオリジナルの仕様は何ら損なわれることがないからである。

# 負の可変性 ``` 3.3 正の可変性と負の可変性 3.3.2 負の可変性 (p.75) ``` > メッセージは必ず本体を持つのだとすると、メッセージ本体のサイズを限定するのは可変性である（ここでは、本体のフォーマットはメセージの設計に無関係であると仮定している）。メッセージの大半が本体を持つが、持たないものも存在するのであれば、可変性が共通性の仮定を破壊することになる。つまり、我々が「メッセージ」の意味であると定義するものの根底にあるとした想定を、可変性が否定するのである。これを**負の可変性**（negative variability）と呼ぶ。負の可変性は正の可変性とはまったく異なるものである。

# ファミリ、レンジ、可変パラメータ、ドメイン ``` 3.4 ドメインと可変性レンジ (p.77) ``` ## ファミリ > 1個の**ファミリ**とは、特定の設計ニーズに適い、1個の「仮想的なマシン」によって生産可能な構成員の集まりだと考えよう。 ## レンジ > そのマシンが生産可能であるファミリ構成員の全体を指して、**レンジ**（range、値域）という用語を用いる。 ## 可変パラメータ > ここで述べているマシンは、入力、ノブ、スイッチ、レバーを持ち、それらにより構築しようとするファミリ構成員の特性を制御することができる。この入力を**可変パラメータ**（parameter of variation）と呼ぶ。 ## ドメイン > **ドメイン**（domain、定義域）という用語は、1個のファミリのすべての可変パラメータに対する正当な値の組み合わせ、あるいは、その可変パラメータのうちの限定されたいくつかのものに対する正しい値の組み合わせを示している。

# 可変性と同値集合、不特定形 ``` 3.4 ドメインと可変性レンジ (p.77) ``` > 共通性分析によって、重要な共通性を把握しようと考えるのが常である。それにより、再利用が促進されるからである。しかし、可変性を疎かにしてよいとは考えていない。疎かにするのではなく、それに**規則性を与えたい**のだ。数多くの可変性を**同値集合**（equivalence）に抽象化することができるのであれば、少数の単純なパラメータですべての可変性を記述できる望みが持てる。この同値集合自身は、3.2節で注意を喚起しておいたように、そのドメインの共通性における不特定形（an anonymous form）になる。これは抽象の1種であるが、ソフトウェアファミリをその構成員の持つ共通性から形作る際に用いる抽象とは別物である。少し飛躍したアナロジではあるが、これは、自然界が共通の遺伝形質を共有する種を形成し、同じ種に属する各々の個体の可変性を管理している方法と似ている。 3.2節の該当箇所は以下のとおり。 > 共通性自身が可変性のヒントになることも多い。例えば、以下のような共通性を考えてみよう。 > > 「`TextEditingBuffers`であればどのようなものでも、何らかのワーキングセットアルゴリズムを持つ」 > > 間違ってはいけない。これは共通性である。そして、可変性が存在する箇所を指し示している。`TextEditingBuffers`は、どのようなワーキングセットアルゴリズムを持つかという点で変化する。意味のある可変性は、大部分がこの手のカテゴリのものである。 ここでは`ワーキングセットアルゴリズム`は`同値集合`かつ`不特定形`である。ステートマシンで考えると、「`UserFSM`（共通性：集約した振る舞い、p.255）は、1つ以上の`State`（不特定形）を持つ」ということになる。`State`は`共通性`であるが、`可変性`を管理している。

# 設計のツボ ``` 3.4 ドメインと可変性レンジ 3.4.1 例：Text Editing Buffers (p.78) ``` > 可変性ドメイン集合は設計の「ツボ」である。適切なドメイン集合の組を可変パラメータに代入することにより、ソフトウェアの設計としてのファミリ構成員の生成を制御することができる。優れた設計であれば、プログラミング言語を用いてその共通性が適切に表現できるが、可変パラメータをどのように表現するかにも、設計の良し悪しがかかっている。

# バインディング時期 ``` 3.5 バインディング時期 3.5.4 バインディング時期の候補 (p.80) ``` - ソースコード時（Source Time） - コンパイル時（Compile Time） - リンク（とロード）時（Link (and Load) - 実行時（Run Time） - 初期設定時 - 運用時 ソースコードに埋め込まれる共通性と異なり、可変性はどこかのタイミング（時期）でバインディングしなければならない。 ``` 3.5 バインディング時期...

# デフォルト ``` 3.6 デフォルト (p.82) ``` > デフォルトは、可変パラメータがアプリケーションに影響を与えることがあまりない場合に有効である。 影響の大きなパラメータについては、アプリケーション側で明示的に指定する方が好ましいだろう。 ## 後方互換性のためのデフォルト 私自身の経験では、リリース済みのソフトウェアに新しい可変点を追加した際に、後方互換性のためのデフォルトを用意することがよくある。 [ドメイン特化言語の文法定義によるデフォルト値](https://github.com/phpmentors-jp/pageflower-bundle/blob/d6b1dc888d4ac17e87e710527584fac94ad63848/src/DependencyInjection/Configuration.php): ``` php

# ドメインとレンジ ``` 3.7 可変性テーブル (p.83) ``` > `TextEditingBuffers`には、出力型、キャラクタセット、ワーキングセット管理技法、デバッキングコードの持たせ方というドメインにレンジがあることがわかる。このテーブルの列は、レンジを持つドメイン、そのレンジのバインディング時期、デフォルト値を表す。 可変パラメーター（可変性ドメイン）`出力型`を`データベース`とした場合にできるアプリケーション、`RCSファイル`とした場合にできるアプリケーション、…がドメインに対するレンジとなる。

# ドメイン間の関係と可変パラメータ ``` 3.8 可変性の落とし穴 (p.84) ``` > 2つのドメイン間に関係があるというだけでは、片方のドメインがもう一方のパラメータになるということにはならない。すべてのドメインが、可変パラメータの組に確実に関係したものになっていることが必要なのである。