Atsuhiro Kubo

# ソリューションドメインとしてのパターンの力 ``` 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン プログラミング言語を超えるパターン (p.158) ``` > プログラミング言語では直接表現できないようなものが、パターンでは表現できることもしばしばある。マルチパラダイムデザインでは解決策を言語機能レベルで打ち立てるのに対して、パターンはどのように課題を解くかを明示的に示し、また設計する上での洞察にも富む。優れたパターンは、そのパターンの読者に対して、何を行うべきかを指示し、その結果がどのようになるかを示唆する。

# パターンのカテゴリ ``` 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン プログラミング言語を超えるパターン (p.158) ``` > 特に根拠があるわけではないが、パターンは3つのカテゴリに分類することができるだろう。すなわち、フレームワークパターン、デザインパターン、イディオムである。 ## パターンのスペクトル フレームワークパターン---デザインパターン---イディオム ## フレームワークパターン 例：`Client/Server` ## イディオム > パターンスペクトル上、フレームワークパターンと反対の極地にあるのがイディオムで、実装する際に使用するプログラミング言語要素に密接に関係している。 ## デザインパターン > デザインパターンは中間にあり、スペクトルのその領域では、解構造によりアプリケーションンの構造を構築するということを行うのである。したがって、マルチパラダイムデザインが対象とするのと同じ変換を扱うことになる。

# パターンとマルチパラダイムデザイン ``` 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン パターンとマルチパラダイムデザイン (pp.158-159) ``` ## パターンとマルチパラダイムデザインの比較 | | パターン | マルチパラダイムデザイン | | --- | --- | --- | | 解決の方針 | ドメインに固有の、繰り返し登場する課題を解く |...

# マルチパラダイムデザインで作るドメインモデルの構造 ``` 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン パターンとマルチパラダイムデザイン (p.159) ``` > マルチパラダイムデザインは、アプリケーションドメインとソリューションドメインを互いに織り合わせて、1つの構造に収束させる。この構造は、それぞれのドメインのフォースを調和させたものである。 ドメイン駆動設計のモデル駆動設計に近いが、ドメイン駆動設計に比べるとソリューションドメインがアプリケーションドメインと同等かそれ以上の重要性を持つのがポイントだろう。 ここでの`フォース`は、p.158で述べられている意味だろう。 > 優れたパターンの多くでは、トレードオフについても議論されるのが一般的で、これは**フォース**（force）と呼ばれている。

# パターンの役割 ``` 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン ソリューションドメインの構成要素に対する別名 (pp.159-160) ``` > 共通性と可変性は、大部分の設計手法やツールの要となるものだ。共通性と可変性に関して繰り返されるパターンは、本書でパラダイムと呼んでいる設計スタイルを支援できるように、その要をプログラミング言語に置くことが多い。その共通性と可変性の組み合わせの中には、プログラミング言語で実現されるのが望ましいといえるほどには一般的だと考えられないものもある。しかし、たとえそうだとしても、設計の語彙にできるほどには一般的である。このような要素がパターンとなり、アプリケーションドメインとソリューションドメインに存在する抽象を補うことになる。 パターンについてジェネレーティブプログラミングには以下のような記述がある。 > 抽象度が高まっていけば、パターンとイディオムはたった1つのフレーズを表すといえます。この抽象度は、言語機能の中で高まっていくものかもしれません。一度、あるデザインパターンやイディオムが言語機能になれば、それはパターンとしての骨子を失わせます。それが、これまでの感覚におけるデザインパターンやイディオムであるとは、もはや考えられないでしょう。ちょうど、継承がデザインパターンであるとは考えられないようにです。その一方で、デザインパターンを記述する書式は、ある固有な問題を解決するための言語機能の適用性を記述するために、有用なままであるでしょう。 > ― [ジェネレーティブプログラミング (IT Architects’Archive CLASSIC MODER)](http://www.amazon.co.jp/gp/product/479811331X?ie=UTF8&tag=iteman-22&linkCode=as2&camp=247&creative=1211&creativeASIN=479811331X) p.274 第8章 アスペクト指向プログラミング

# ソリューションドメインの拡張 ``` 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン (p.161) ``` > 表6.2にC++のソリューションドメイン構造をまとめた。これにC++のソリューションドメインに対して「パターンソリューションドメイン」を追加すると、共通性と可変性の豊富な組み合わせを表現でき、さらに、C++という言語のみから生じる表現を超えた要素を用いるソリューションドメインが支援されることになる。これをまとめたのが表6.3である。このテーブルはC++ソリューションドメインのテーブルの拡張だと見なすことができる。**変換分析**（7.2節）を行う際には、この2つのテーブルを1個のものと考えればよい。 プログラミング言語に加えて、フレームワーク・ライブラリ、パターン、モデリング技法（例：リレーショナルモデリング）等でソリューションドメインを拡張でき、それらを1つのドメインと見なすことができる。

# 構造の共通性のない共通化 ``` 6.12 ソリューションドメインの拡張要素 6.12.2 デザインパターン (p.162) ``` > `Bridge`を考えるとき、ファミリ構成員の構造には共通性はないと仮定することもできる。そう考えると、各ファミリ構成員は空の土台の上に独自の構造を持つことになる。すなわち、ファミリ構成員は互いに完全に無関係の構造を有し、負の可変性については考慮しなくてよい。このとき共通性は、ファミリ構成員と関係するシグネチャ（基底クラスのインターフェイス）という、さらに広いコンテキストから生じることになる。 https://github.com/phpmentors-jp/mpdosaka/issues/6#issuecomment-104823669 も参照のこと。

# 可変性と共通性の関係 ``` 3.1 可変性：生の芳香 (p.71) ``` > 共通性が設計の骨格であり、骨組みを形成するものなのに対して、可変性は血肉であると言える。アーキテクチャから考えれば、共通性分析はアーキテクチャを永らえさせるものであり、それに対して可変性分析はそのアーキテクチャを利用し得る形に仕立て上げるものということになるだろう。 具体的な例を挙げると、ドメイン特化言語が可変性を表現し、その背後にあるドメインコンポーネントが共通性を表現するということになる。

# 可変性と共通性次元の関係 ``` 3.1 可変性：生の芳香 (p.72) ``` > アプリケーションドメインの構造は、同一の次元軸に沿って可変させることができる。その軸を決めるのが共通性である。 選択された共通性の設計次元によって可変性の特性が定まるということだと思う。

# 可変性分析の実施タイミング ``` 3.1 可変性：生の芳香 (p.72) ``` > 可変性分析と共通性分析の両者で共通性カテゴリの用語を使用するので、この2つのアクティビティは同時に実施されるべきだろう。