>>87
木構造を表現するのに適切なデザインパターンだと思うけど？> Composite pattern

>>79,81
パターン言語には、その(solution)解法を適用する場合のコンテキスト
（背景・解決する問題の状況）や、force（制約・制限）等が書かれているはず。
更に言えば、具体的な事例や、そのパターンを適用した際に起こる副作用とかトレードオフ等、
こういった一連の状況を指してパターンと呼んでいるんじゃなかった？

solutionの部分だけを指してパターンと呼んでいる人が多い様に見受けられる。
FAQにもパターンという表現は誤解を招きやすい言葉だったって書かれているけどね。
だからと言って誤解されたままでは有益な議論は出来ないよ。
一言で説明するのは難しいかも知れないけど、設計と言い切ってしまうのはどうかな？と思う。

デザインパターン => オブジェクト指向での設計上の問題に対する解決策とそれに関する知見。

>>85
かえってごちゃごちゃになったのなら、どうしてそうなったのか考えてみよう？何か原因あるはずだよね？
ここで、パターン使ってこうなったからパターンは使えない、なんて短絡的な発想はせずに。
どうすれば、その問題をスマートに解決出来るんだろうと考えてみる。

例えば、Observerパターンで知られている問題点は、
Subjectが複数になった場合に保守や拡張が困難になる、その場合はSubjectに中間層を設けるなど。
パターンの説明には必ず関連するパターンへの参照や、例外／制限事項等が書かれているはずです。

クラス図だけ見真似てデザインパターンを使ったつもりに浸っていると、
パターン使った=>更に悪化 という*パターン(繰返しの意味で)*に陥りやすいです。