What is a Design Evolution?
ソフトウェアにおけるデザイン進化とは？
まず、いくつかのレベルでのデザイン活動が考えられる。（全体としての）アーキテクチャレベルのデザイン、コンポーネント（クラスなど）レベルでのデザイン、コードレベルでのデザイン。
実際には、コンポーネントの内と外のデザインは比較的区別しやすいかもしれないが、これらのデザインを厳密に区別することは難しいかもしれない。
「マルチパラダイムデザイン」でコプリンが言っているように、デザインを考える上では、プログラマの思考の中にも厳密な区別はないかもしれない。
[...] プログラマが実務の中でどのように働いているかを調べたならば、たいていのアプリケーションの場合、彼らがアーキテクチャ、設計、実装を線引きしているわけではないことがわかるだろう。彼らの属している企業で採用されている公式の手法でそうすべきだと謳われているか否かに関わりなく、彼らの中には線引きはないのである。
ここでは、デザインパターンを例にあげて、デザインの進化を考えたいと思う。ここでのとりあえずの結論（あるいはデザイン進化の一種）は、デザインのルールの変更*1ということとしたい。
いくつかのデザインパターンは、その適用後のデザインパターンの成長に特定のパターンがある（あるいは、以下で述べるようにどんなデザインにも暗黙の成長ルールがあるかもしれない）。
たとえば、Strategy パターンが適用された状態で、新しいアルゴリズムを追加しようとしたなら、そこには拡張（成長・進化）ルールがある。つまり、Strategy クラス/interface を継承/実装して、新しい ConcreteStrategy を追加する。
一方で、もし、Strategy パターンを適用していないデザインだとしても、拡張ルールが見られる。
public class Context {
private int strategy = 1;public void setStrategy(int strategy) {
this.strategy = strategy;
}public void contextInterface() {
if (strategy == 1) {
algorithmInterface1();
} else if strategy == 2) {
algorithmInterface1();
} else {
// デフォルト or 例外
}
}private void algorithmInterface1() { ... }
private void algorithmInterface2() { ... }
}//新しいアルゴリズムを追加したい場合。
public class Context {
private int strategy = 1;public void setStrategy(int strategy) {
this.strategy = strategy;
}public void contextInterface() {
if (strategy == 1) {
algorithmInterface1();
} else if strategy == 2) {
algorithmInterface2();
} else if strategy == 3) {
algorithmInterface3();} else {
// デフォルト or 例外
}
}private void algorithmInterface1() { ... }
private void algorithmInterface2() { ... }
private void algorithmInterface3() { ... }
}
後者の if を使った例は、リファクタリングの対象となりうる（「パターン指向リファクタリング入門」）。
Strategy パターンへのリファクタリング適用することで、拡張ルールの変更が見られる。この記事では、このようにして拡張ルールが変化（進化）することを、デザイン進化（の一種）と呼びたい。
もちろん、いくつかの疑問に答えていく必要がある。
- すべてのリファクタリングはデザイン進化なのか？
- リファクタリングでないようなデザインの進化は考えられるか？
もちろん、回答すべき重要なこととして、デザイン進化を考えることにどんな意味があるのか？ というものがある。
