Constructing and Exploring Design Spaces
設計者は、どうやって設計プロセスのアウトプットとして解決策を探し、決定する？
グラスの「Software Conflict 2.0」によれば、設計の本質とは：
The essence of design, then, is rapid modeling and simulation.
つまり、設計者は、
- (1) 問題に対する解決策のメンタルモデルを作り、
- (2) 問題に対してそのモデルを実行し（シミュレーション）
- (3) 問題を解決できなかったら、モデルを修正する
- (4) 問題を解決するまで 1〜3 を繰り返す
設計者は、問題に対する解決策で構成される設計空間を探索し、最終的に解決策を決定する。たとえば、アルゴリズムを交換可能にするという問題に対して、if 文を用いる解決策と、Strategy パターンを使う解決策が選択肢となる。
この場合、n 個の（競合する）解決策がすでに存在していると仮定している。しかし、実際には、グラスの例であげたように、解決策の候補を抽出することが、設計プロセスの段階の一つであると考えられるかもしれない。
「設計」と言った場合、「設計プロセス」とそのプロセスの結果としての出力を区別すると便利かもしれない。
上述のシンプルな例でいえば「設計プロセス」は、以下の段階で構成される：
- (1) 問題を解決するであろう解決策の候補を抽出する
- (2) 候補の中から、さまざまな制約（再利用性、進化容易性、シンプルさ、など）を考慮し、解決策の一つを選択する
出力は、実装、つまり、構造を表現するコードである。
入力として「要求（問題）」があり、出力として「構造（解決策、あるいは実装）」がある。
一方で、中間の生成物として、設計候補を考えると便利かもしれない。
たとえば、プログラミング言語の選択は、最終的な解決策を制限する。たとえば、C 言語が提供する解決策の空間と C++ が提供する解決策の空間は異なる。
たとえば「X 言語が使えれば、こういう設計にするのに」といった思考は、共通であると思う。
したがって、メンタル的には、設計の空間と解決策の空間は異なると言えるかも知れない。（理想としての）設計の空間から、（現実としての）解決策の空間へのマッピングができないことがある。
たとえば、アスペクト指向的な思考になれているなら、通常の方法でロギングを実装するという設計案よりも、アスペクトとしてロギングを実装する案が真っ先に思い浮かぶかもしれない。アスペクト指向をサポートしてない言語（たとえばＣ言語）を使っていたとしても、そのようなアスペクトを使う設計案としては思い浮かぶかもしれない。もちろん、解決策へのマッピングができないので、最終的な実装になることはない。
