Evolution Boundary of Design

モジュール（クラスやアスペクト）の構造の進化（あるいは発展・変化）を捉えようとしたときにどの範囲までその進化が及ぶことになることかを考える必要があると思う。なぜそもそも捉えなければいけないのか、捉えると何がうれしいのか、という疑問はとりあえず無視する。

モジュールは 単に 進化しない。設計における決断の結果として進化する。それは、その時における文脈を考慮した上での意図的な進化であり、単に進化するわけではない。

ソフトウェアは、モジュール（or オブジェクト）同士のやりとりで構成される。オブジェクト同士はお互いに協調し合って、何らかの機能を果たす。

デザインパターンは、クラス（オブジェクト）の構造的な協調を明示的に書き示す。たとえば、Strategy パターンは、Context, Strategy, ConcreteStrategy などの役割を持ったオブジェクトが協調してある設計上の問題を解決する。

したがって、構造の進化を考えた場合、単に単体のモジュールの構造の変化を捉えるだけでは不十分であり、協調するモジュールの構造として変化を捉える必要がある（と思う）。

たとえば、Strategy interface へのメソッドの追加は、単にその interface の構造が変化するのではなく、その interface を実装するクラスの構造も変化させることになる。

したがって、モジュールの構造がどういう 意味や機能単位 で協調しているのかという設計の境界を把握することが重要となる。あるモジュールへの構造的な進化の要求は、そのモジュールと協調するどの範囲までを考えればいいのか。

個々のデザインパターンの構造の単位（Strategy でいえば上述した3つの役割を持つクラス）で考えればいいのか。

デザインパターンは、合成される場合がある。ConcreteStrategy の役割を持つあるクラスは、同時に Context の役割も持っているかもしれない。この場合、二つの Strategy パターンが構成する構造の単位を、その構造を構成する個々のモジュールの進化に対する強調的な構造の変化だと見なすのか。

そもそも、モジュールの構造の進化の視点から見た場合、その分析対象は、必ずしもデザインパターンである必要はない。デザインパターンは、出発点として役には立つ。しかし、デザインパターンの本来の目的は、設計におけるモジュール構造を明示的に文章化することではない。

設計を考慮しつつモジュール構造の進化を理解しようとしたとき、そもそも分析のためのツールが足りないことに気付く。語彙が足りないことに気付く。Maman と Gil の Micro Pattern の研究 は、デザインパターンでは足りない語彙の不足を補ってくれる。Micro Pattern は、繰り返し起こる単一のモジュールの構造を特徴を捉え、名前を与える。ただし、複数のモジュールとして繰り返し発生する構造は取り扱っていない。