Design Patterns: Recurring Problem vs. Recurring Solution

研究

デザインパターンの標準的な見方は「ある文脈において繰り返し発生する設計上の問題に対しての標準的な解法を明示的に記述したもの」という感じ。

ある意味では、問題が繰り返し発生するだけでなく、解法も繰り返し発生する。この記事での焦点は、繰り返し発生する問題と解法のどちらが重要なのか、ということ。

注意：上述したデザインパターンの定義は、正確に文献を参照して書いているわけではないので、前提としている定義が誤っていれば、以下の話の信頼性は失われる

そもそも、なぜ、問題と解法のどちらかが重要なのかを考える必要があるのかを。まず書く。

恐らく、根本的な問題は、安定性の違いにあるのではないかと思う。問題よりも解法の方が変化しやすい。

たとえば、デザインパターンが提供する解法は完璧ではなく、単なる回避策であると言われたりもする（正確に文献を参照するのは面倒なので省略）。

たとえば、AspectJ を使って デザインパターンの実装を改善しようという試みなどがある。他にも、提案しようとしている言語を評価するための例題やケーススタディとして、従来（Java など）のデザインパターンの実装の欠点を挙げ、その欠点を解決するような研究報告が多い（僕のクソ論文を参照）。


ここから分かるのは、取り扱おうとしている問題（つまり、各デザインパターンが解決しようとしている問題）と比べて、その解法は、不安定だということ。つまり、実装する言語が変われば、解法も変化する（このことは、昔から指摘されているし、GoF でも言及されている）。


ただ、現状の研究上の課題としてあると思うのは、異なる言語が提供する解法間の関係。

ここでは、簡単のために、大きく異なる言語（たとえば Java と CLOS などのダイナミックな言語）がそれぞれ提供する解法は無視して、似ている言語（JavaとJavaを拡張した言語）or 言語ファミリ が提供する解法だけを考えたい。

言語が異なれば、解法は異なる。とはいえ、実際に何が異なるのか。

  • それとも、AspectJ の実装と Java の実装は 共存するのか。その場合、割合はどうなるのか。従来のJavaでは、ある問題に対しては 9 割の可能性で Java のデザインパターンの実装が適切だったとすると、AspectJ の存在にとってその割合はどう変わるのか。5割が Java の解法で 4 割が AspectJ の解法なのか。その場合、この状況を パターン と呼べるのか。

このような疑問に取り組んでいる研究者は少ない。言語設計者は、少なくとも論文上では、デザインパターンを例題やケーススタディの一例として見なすことが多い（僕のヘッポコ論文を参照）。逆に、パターン研究者がこの問題に取り組んでいるケースを僕は知らない。


ここでは、デザインパターンということに焦点を当てて議論を進めたけれど、設計における問題と解法という視点からは、ここでの議論はデザインパターンに限定されない。デザインパターンは、設計における比較的重要な問題を取り扱う。一般の設計においては、それほど重要でない設計上の問題も繰り返し発生する。そして、恐らく、解法も繰り返し適用される。そして、その解法も、もちろん、その言語を用いるかによって影響を受ける。


まとめ：
デザインパターンは、解法だけでなく、問題も記述する。デザインパターンかどうかにかかわらず、つまり、解法が繰り返し発生するかどうかにかかわらず、設計における問題は繰り返し発生する。そして、問題は解決されなければならない。適用される解法は、最適でないかもしれないし、適切でないかもしれない。誤っているかもしれない。不十分かもしれない。しかし、解法の頻度は（定量的でなくても）観測できるかもしれない。分析できるかもしれない（言語設計者がやってるのはまさにこれだと思う：問題の分析とそれに対する解法）。

言語の拡張に伴う解空間の拡張は、設計における選択肢を増やす。デザインパターンにおける実装上の解法は、選択肢の増加のため、安定でなくなる可能性がある。解きたい問題は同じかもしれない。ただし、解法は、もはや、一方通行な、暗黙的に選択してよいパスを形成していないかもしれない。

参考：

評価対象としてのデザインパターンの使用に関する考察
http://www.ncfreak.com/asato/papers/bench-dp-final.pdf