第2章 共通性分析

[iteman]

共通性と可変性は、ほとんどすべてのソフトウェアパラダイムにとって、主要な特性である。この章では、共通性について調べていこう。共通性はアプリケーションのファミリを定義する。そしてファミリはマルチパラダイム開発におけるソフトウェア抽象の最も基礎的な概念である。
― 新装版　マルチパラダイムデザイン p.37

[hidenorigoto]

2.1 共通性：抽象のエッセンス

p.38

共通性分析は、結合度と凝集度（coupling and cohesion）という設計原理と同調するものだ。ソフトウェア設計では、なるべく個別に作成できメンテナンスできるプロダクトと構築しようと努める。分割がうまくいくと、結合度が低く凝集度の高いプロダクトが作成できる可能性も高くなる（結合度が低いと、チームのメンバが個別に働くことができる。凝集度が高いと、各設計成果が概念的な一貫性を持つものになり、そのシステムは理解しやすいものになる）。

基本的な立場

2.1.1 演繹的共通性と帰納的共通性

p.39

自動車を目にしたことがあるのであれば、それを見たときに、自動車だと認知できる。その年の新式の自動車を見たとしても、これまで見たことのないその実体を自動車だと認知できるのだ。それは自分たちの経験の内にある自動車とは詳細が異なっているが、それでも一般の自動車に共通しているアスペクト（様相）を共有している。

アスペクト（様相）＝相貌

2.2.2 設計の認識論

p.46
グラウンデッド理論（grounded theory）
http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%A9%E3%82%A6%E3%83%B3%E3%83%87%E3%83%83%E3%83%89%E3%83%BB%E3%82%BB%E3%82%AA%E3%83%AA%E3%83%BC

2.3 共通性次元と共通性カテゴリ

p.50
共通性の次元の例

• Structure: 構造
• Name and behavior（Identifier、Signature、Type）: 名前と振る舞い（識別子、シグネチャ、型）
• Algorithm: アルゴリズム

2.3.1 データ構造

p.53

例えば、Windowはクラスとして適切なものである。これは関連する責務を集めた座（locus）を形成している。

"locus" (Latin for "place" or "location")

ここで言っている「座」がよく分かりません。

2.4.2 名前と振る舞い

p.63

単純なドメインNumberを考えるとしよう。このドメインの中には、operator+、operator-、operator*などの算術演算子のファミリがある。

この記述から、「ドメイン」と「ファミリ」という言葉を理解できる。図2.4(p.50)左側で、Numberを頂点とする階層全体が「Numberドメイン」である。

• Numberドメイン
• Numberとその派生クラスComplexやReal、Imaginaryという個々はサブドメイン
• このドメインに、operatorファミリがある
• operatorファミリの構成員（+や-）を、サブドメインに割り付ける (p.50)

疑問

「共通性分析によって得られるカテゴリ」＝「ドメイン」とするならば、共通性分析には様々な次元があって、1つの対象に対して次元ごとにいろいろなドメインを見いだしうる。上の例では、Numberという構造から見たドメインと、operatorという振る舞いから見たドメイン、と言えることになる。この後者をドメインと呼ぶのかどうか、本の用例などを見ると曖昧なように思う。

2.5 共通性分析のレビュー

p.67

共通性分析はカテゴリを生み出す。ここでカテゴリと言っているのはドメインのことだが

共通性分析によって得られるカテゴリ　＝　ドメイン

共通性分析における、自問自答

• ファミリのすべての構成員に対して、真（true）となるものであるのに、いまだ記述されていないような特性が存在しないだろうか。
• 共通性をさらに正確に記述することはできないだろうか。
• 共通性は厳密だろうか。
• 共通性は矛盾しないだろうか。

2.6 共通性とシステム拡張

p.68

我々はドメインの語彙集に定義された構成要素に共通性を探し出すだけでなく、その語彙集が明日になっても今日と同じものであるかどうかを尋ねる必要がある。

時間的にも安定している共通性を探し出すということ

p.69

優れた共通性分析が弾力的な設計を引き出すということは、多くの場合、真であることに違いがない。

[iteman]

@hidenorigoto ここではカテゴリ＝ファミリであると思いますが、ドメインとファミリの関係は1.3.5 ファミリと共通性分析 (pp.11-12)に書かれていて、ファミリはドメインといえるが、ドメインはファミリを形成しないものがあるため、必ずしもファミリとはいえない、と理解しました。

[hidenorigoto]

@iteman ありがとうございます。ファミリとドメインは、その言葉が指す対象が似ているけれども、表している事柄は違いますね。

[iteman]

分析の基礎的ツールとしての抽象

2.1 共通性：抽象のエッセンス (p.37)

ソフトウェア設計における大きな進歩はすべて、抽象に対する新しい見方の獲得の上に成り立っていることがわかる。抽象というのは、自然言語で普通に使われる場合には、一般性（general）に焦点をあて、特殊性（specific）は取り上げないことを意味している。ソフトウェア開発では、共通しているものは何かを強調し、詳細は省くことにより、抽象化を行っている。抽象化は分析の基礎的ツールである。

[iteman]

抽象とパラダイム

2.1 共通性：抽象のエッセンス (p.37)

「ソートすること」という抽象は、オブジェクトパラダイムから生み出されるものではなく、手続きパラダイムに基づくものだ。しかしそうであっても、それが主要なビジネス上の抽象であることに変わりはない。

抽象はオブジェクトパラダイムのみに由来するものではない。

[iteman]

共通性と抽象

ソートすること

2.1 共通性：抽象のエッセンス (pp.37-38)

ソーティングアルゴリズムを考察する際に、そのデータがランダムに並んでいることがわかったならば、クィックソート（quicksort）を使用しようと考えるだろう。…高レベルの設計ではこのようなアルゴリズムをすべて等しく扱うことができるが、それはこれらに共通点があるからだ。つまり、どのアルゴリズムであっても「ソートする」。ここでは、この共通性が抽象化のベースになっているのである。

行列

2.1 共通性：抽象のエッセンス (p.38)

代数行列のパッケージを作成しているのであれば、行列（matrix）という抽象を考えることができるだろう。もちろん、行列と言っても、さまざまな種類の行列があることを我々は知っている。疎行列、単位行列、上対角行列、下対角行列など。これらはすべて実装が異なる。しかし、共通した振る舞いを持つためにグルーピングすることができる。この場合にも共通性が抽象を可能にしているのである。

• 共通性が抽象化のベースになっている。
• 共通性が抽象を可能にしている。

[hidenorigoto]

@iteman

p.57の以下の2つの箇所、英語ではどういう文章なのか分かりますか？

あるいは、表示可能な（displayable）オブジェクトをインスタンス生成するクラスの1つのメンバ関数として、displayOnを定義することもできるだろう。

継承により関係づけられたクラスのファミリの部分として、これらの関数を仕立て上げることもできる。

[iteman]

@hidenorigoto 博士論文のバージョンになりますが、以下のようになります。

Or we could make displayOn a member function of each class whose objects are displayable:

Or, we could make them part of a family of classes that we relate by inheritance:
― Multi-Paradigm Design, Ph.D. Thesis p.72

[hidenorigoto]

@iteman ありがとうございます。
後者の例は、displayOnは1つのファミリを構成するけれど、それが、別のファミリ（Windowクラス）の部分にもなっている、ということですね。

[springkuma]

2.2.2 設計の認識論

p.46
グラウンデッド理論（grounded theory）
http://ja.wikipedia.org/wiki/%E3%82%B0%E3%83%A9%E3%82%A6%E3%83%B3%E3%83%87%E3%83%83%E3%83%89%E3%83%BB%E3%82%BB%E3%82%AA%E3%83%AA%E3%83%BC

こちらのリンクもなかなかおもしろかったです。

http://web.cc.yamaguchi-u.ac.jp/~ysekigch/qual/grounded.html

これを読むと、グラウンデッドセオリーも、カテゴリー理論との関わりが大きいのかなと。

[kumamidori]

p.40
新規に開拓するドメインに対する設計では、最初に行われる直観で行うとも言えるフェーズを省略する。
必要となる原形だけを借りて、ドメイン自身を観察して分割のための鍵を探す。
前もって予想を立てておいた分割基準を用いた問題から抽象を捻りだすのではなく、ドメイン自身から抽象を導き出す。

→　 文章が難解に感じるのですが、「経験的に分からない場合もあるよね」というような単純な話をしていると思っていて良いでしょうか・・・。

[kumamidori]

p.41
ただし、モジュールがドメインに境界を引くことは必然ではない。
どのようなビジネス概念であっても、その論理的な塊（凝集）と、その概念を表現するプログラミング言語の能力の間には、
テンション（緊張、伸縮）が存在する。

→　言い換えると、人が理解しやすいもともとの概念レベルでのグルーピングと、構造化したモジュールの境界とでは、成り立ち方がそもそも違うので、自然に一致したりはしない。

[kumamidori]

【不明点の質問】
p.41, p.42 あたりに出てくる「モジュール」という言葉は、
「パッケージ」（Ruby の Gem や PHP の Composer）とは違う意味なのでしょうか？
コンパイル可能なソースコード単位、というような意味なのか、分かりませんでした。
http://www.cc.kyoto-su.ac.jp/~hxm/cstext/prog06.html

[kumamidori]

p.42
アルゴリズムに関する共通性は多重定義で、振る舞いの共通性はpublic継承で、そして構造上の共通性は集約（aggregation）で表現できる、ということに気づくことがあるだろう。

今まで、自分の中では「アルゴリズム」と「振る舞い」を同じような意味の言葉としてに一緒くたに使っていた（どちらも、手続き、機能、動的、というようなイメージだった）ので、意味を確認。

• アルゴリズム： howのこと。戦略、作戦、方策。
• 振る舞い：　機能。

overload

Scala例（メソッドの多重定義。分数と整数の間で加算を行うメソッド）：

class Rational(n: Int, d: Int) {
    private val g = gcd(n.abs, d.abs)
    val numer = n / g   // 分子
    val denom = d / g  // 分母
    def + (that: Rational): Rational =
        new Rational(
            numer * that.denom + that.numer * denom,
            denom * that.denom
    )
    def + (i: Int): Rational =
        new Rational(number + i * denom, denom)
    // 中略
}