ソフトウェア設計の原則

ソフトウェア設計は、どういった原則にもとづいて行われるのか。最も重要な、最も基礎となる原則は何か考えてみた。分割統治か、分割とモジュール化か、段階的詳細化か、モジュールの独立性（凝集度／結合度）か、外部仕様と内部設計の関係か。

いまではソフトウェアは小さく分割して作り上げるのは当たり前ではある。だが１つのファイルで１つの手続きで分割などせずGOTOをバンバン使って作り上げることはできる。だから分割に関する原則は根源的ではない。

では「設計というのは、要件／外部仕様が与えられて、その内部を詳細化することだ」でいいのか。だが、いつもきっちりと仕様が与えられるかというと、段階的にしか明確にならない状況でも設計を開始しなければならないこともある。設計に対する要件や仕様とは何なのかを突き詰めていくと、最も根源的な設計原則が見えてきた。

設計には課題が与えられる。設計はその課題を解決するために行う。これが最も根源的な原則だ。言うならば「課題解決の原則」である。もう少し丁寧に記述するなら、「対象に与えられた課題（＝要件／仕様）に対して、考えられる解決策（＝設計）の候補を挙げ、それらの優位性を判定して、最適な解決策を１つに絞り込む」ということになる。当たり前のように見えるが、意外と徹底されていない原則ではある。最適解であるかどうかの妥当性確認も伴う必要がある。

分割するかしないかは、課題に対する解決策の候補として挙げて評価すればよい。学習のためにアルゴリズムを確認するだけのようなプログラムでは分割など考えなくてもいい。

課題解決の原則は、設計のどの抽象レベルにも適用されなければならない。アーキテクチャ設計、詳細設計、モジュール設計（＝クラス設計）などのどの段階においてもだ。それぞれの段階で、設計課題の抽出、その課題に対する解の導出、選出された最適解の妥当性評価を行う。解の導出では、解決策候補の抽出、各候補の詳細化、候補の絞込みを行うことになる。

通常、設計課題には開発容易性や保守性、拡張性・変更性などの要件があり、そのための解決策として分割統治、モジュール分割などの原則を適用する訳だ。