Atsuhiro Kubo
Atsuhiro Kubo
# 2つの仮想関数のグルーピング方法 ``` 6.8 仮想関数 (p.135) ``` > 仮想関数のグルーピングには2つの方法がある。1つ目は、アプリケーションドメインの抽象データ型を実装するクラスの中に仮想関数をグルーピングする方法、2つ目は、異なるクラスの仮想関数を1つの継承階層へとグルーピングする方法である。 解説求む。
# 振る舞いと意味 ``` 6.8 仮想関数 (p.135) ``` > 要するに、仮想関数群は、外部から観測可能な振る舞い、すなわち意味を共有する。例えば、`Shape`（形）クラス以下に階層を形成するクラス群は、すべて`draw`（描画）メンバ関数を共有する。このようなメンバ関数はほかにも数多くある。「描画される」というのは、すべての「形」が持つ振る舞いである。
# ポリモーフィズム ``` 6.8 仮想関数 (pp.136-137) ``` > ポリモーフィズム[CardelliWegner1985]とは、「多くの形態」を意味する。共通性と可変性という本書の視点に合わせて、これを次のように言い換えることも可能である。 > 「ポリモーフィズムは、関連するいくつかの形態に何か共通するものがあるがそれぞれの形態は別個であるということを意味する」 図6.8も参照のこと。
# C++における負の可変性の表現方法 ``` 6.11 負の可変性 (p.138) ``` - テンプレートの特殊化 - デフォルト引数 - 間接参照（データメンバキャンセルのため） - private継承（振る舞いのキャンセルのため） - 共用体 - `#ifdef`
# 負の可変性はルールの例外 ``` 6.11 負の可変性 (p.138) ``` > C++のそれぞれのパラダイムは、**バリエーションのルール**を持つと見なすことができる。「オブジェクトパラダイム」では、バリエーションのルールは次のようになる。「ファミリの構成員は、基底クラスの中に据えた共通性に対して、新たな関数とデータを追加することができる」。ほとんどのパラダイムにおいて、可変性は共通性を侵すことはない。しかし、負の可変性は共通性を侵すため、バリエーションのルールに違反する。つまり、負の可変性はルールの例外なのである。
# 負の可変性の反転 ``` 6.11 負の可変性 6.11.2 負の可変性とドメイン分割 (p.148) ``` > 前項の技法は小さな負の可変性に適用される。負の可変性が大きくなるにつれ、バリエーションとしての特徴がなくなってくる。それは共通性となり、取り残された反対側が今度は可変性となるのだ！大きな負の可変性は、しばしば正の可変性として扱われなければならない。
> > 仮想関数によるグルーピングには2つの方法がある。1つ目は、アプリケーションドメインの抽象データ型を実装するクラスの中に仮想関数をグルーピングする方法、2つ目は、異なるクラスの仮想関数を1つの継承階層にグルーピングする方法である。 > - 1つ目の方法 > 5.1.3(p.113)では、純粋仮想関数(実装を持たない仮想関数)を使ってComplexという抽象データ型を定義し、その派生クラスでoperator+=を実装していた。この場合、ADTのinterface-実装対が1つのグループとなっている。 > - 2つ目の方法 > 仮想関数はADTに限ったものではなく、単にシグネチャと意味が共通したメソッドを継承階層にまとめるのに使っても良い。基底クラスは「純粋」仮想関数でなくともよく、デフォルトの実装を持っていても良いし、シグネチャも共変性を持つ範囲で一部変えることができる。アプリケーションドメインから抽出されたクラスだけでなく、デザインパターン等のソリューションドメイン側の実装テクニックにも使える、といった意味合いを言っている？ ありがとうございます。別々のクラス階層にいたとしても、それらに一致するシグネチャを抽出してインターフェイスとすることができるよ、ということですね。これは複数のドメインにまたがるようなドメイン（相対的な水平ドメイン）の抽出ともいえそうです。
# 分類階層と多重継承 ``` 6.12 ソリューションドメインの拡張要素 6.12.1 多重継承 (p.153) ``` > 多重継承の「正統な」使用法は分類階層の表現であり、オブジェクト指向設計との関わりが深い。ある型があるカテゴリに属するとき、その型はそのカテゴリのサブタイプとして表現されるべきだろう。 ワークフローエンジン[Workflower](https://github.com/phpmentors-jp/workflower)の型[ActivityInterface](https://github.com/phpmentors-jp/workflower/blob/master/src/Workflow/Activity/ActivityInterface.php)の例:  ``` > パターンにはさまざまなものがあるが、共通性／可変性分析の範囲内に含まれるパターンも存在する。つまり、本書の対象としている領域を表現するパターンが存在するのである。このことは興味深く、注目に値するもので、もしかしたら驚くべき発見だと言ってもよいかもしれない。現在、人気を博しているデザインパターンの多くが、共通性と可変性の典型的な配置をほとんど超えないのである。ここから、設計手法というものは、共通性分析の領域に数多くのパターンを織り込んでいるものだと考えることができるだろう。つまり設計の性質を考えれば、個々のパターンを「覚えなくてはいけないもの」とか「適用しなくてはいけないもの」といった例外として考える理由はどこにもないのである（このことについては、前の節で多重継承を例にとって、それが真であるということを見てきた）。 パターンを設計の例外としてではなく、共通性／可変性分析を含む一般的な分析・設計の例として捉えるのがよいということだろう。
# ホットスポットと可変パラメータ ``` 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン (p.157) ``` > Gammaたちは、『デザインパターン』の中で、彼らのデザインパターンをまとめた表を掲載している（[Gamma1995]、原書p.30）が、そこで設計上の可変性を利用している。この章でもたびたび可変性の表を参照してきた。Wolfgang Preeは、このような変更部位をホットスポット（hot spot）と呼んでいる[Pree1995]。**ホットスポット**は、マルチパラダイムデザインで言えば、可変パラメータに類似した概念である。