When a Decision is a Design Decision - asatoの技術的な内容の日記

設計とは？設計における決定とは？

設計とは、ある問題に対して解決策となるような構造を与えるアクティビティのことである。

とある。「ModernC++ Design」によれば、設計とは：

ソフトウェアシステムの設計とは、各々の解決領域を組み合わせて解決策を選択することなのです。

とある。

たとえば、ある単純な（アルゴリズム的な）処理を行うことを考えてみる。以下のような、少なくとも3つの解決策が考えられる：



// 解決策1

public class Main {
  public static void main(String[] args) {

	

    new Main().run();

  }

	

  private void run() {

    System.out.println("アルゴリズム");

  }

}



// 解決策2

public class Main {
  public static void main(String[] args) {

	

    new Main().run();

  }

	

  private void run() {

    algorithm();

  }

	

  private void algorithm() {

    System.out.println("アルゴリズム");

  }

}



// 解決策3

public class Context {

	

  public void algorithmInterface() {

    System.out.println("アルゴリズム");

  }

}
public class Main {
  public static void main(String[] args) {

	

    new Main().run();

  }

	

  private void run() {

    new Context().algorithmInterface();

  }

}

解決策1では、アルゴリズム処理のコンサーンが分離されていない。解決策2では、手続き（関数 or メソッド）によって、分離されている。解決策3では、クラスを導入することで、さらにコンサーンを分離している（Mainクラスは、アルゴリズム処理のコンサーンについて何も知らない）。

はじめにあげた設計の定義からいえば、これら3つの解決策の中から特定の解決策を選択（決定）するアクティビティを設計と呼んでいいのだろうか？

クラスを導入するかどうかの決定は、設計に関わる決定に思える。

では、メソッド（関数 or 手続き）を導入するという二つ目の解決策は、設計に関わる決定だろうか？少なくとも、コンサーンの分離に関わることであるとは言える。Kiczales らによれば：

Programming language designers have developed numerous mechanisms for separation of concerns (SOC) at the source code level, including procedures, object-oriented programming and many others. [...]
Our goal is understand what kinds of concerns each mechanism best separates, and how the mechanisms work together to separate multiple concerns in a system. [...]

また、どういった基準でソフトウェアを関数に分解（decompose）するのかといったことに関わる決定が、オブジェクト指向以前のパラダイムには存在したはずである。もし、どういった基準でソフトウェアをクラスに分解するのかいった決定のみを設計のアクティビティと呼ぶなら、オブジェクト指向以前には、そのようなアクティビティは存在しなかったことになる。

他にも、環境が異なれば、上記の3つの解決策における決定は単純（クラスで分割するのが正しい）ではなくなる。たとえば、携帯ゲームのような利用できるサイズに制限のある環境では、クラスで分割すること（解決策３）は常に適切な決定になるとは言えない。

したがって、上述の3つの解決策は、一つの設計（解）空間に含まれると考えられ、解決策の一つを選択するアクティビティは、設計における決定であると考えられる。