よくできたソフトウェアシステムは、クリーンなコードを書くことから始まる。レンガの出来が悪ければ、その建築は優れたものにはならない。一方、たとえよくできたレンガを使っても、ぐちゃぐちゃなもの作ってしまうことがあり得る。そこで登場するのが「SOLID」原則。
SOLID原則は、関数やデータ構造をどのようにクラスに組み込むのか、そしてクラスの相互接続をどのようにするのかといったことを教えてくれる。
SOLID原則の目的は、以下のような性質を持つ中間レベルのソフトウェア構造を作ること。
- 変更につよいこと
- 理解しやすいこと
- コンポーネントの基盤として、多くのソフトウェアシステムで利用できること
Single Responsibility Principle
個々のモジュールを変更する理由がたったひとつだけになるように、ソフトウェアシステムの構造がそれを使う組織の社会的構造に大きな影響を受けるようにする。
モジュールはたったひとつのアクターに対して責務を負うべきである。
Opne Closed Principle
ソフトウェアの構成要素は拡張に対しては開いていて、修正に対しては閉じていなければならない。
ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべき。
Liskov Substitution Principle
サブクラスは、スーパークラスと置換可能でなければならない。
Interface Segregation Principle
包括的なインターフェースがあるより、いくつかの特定のインターフェースに分割すべき。
Dependency Inversion Principle
ソースコードの依存関係が（具象ではなく）抽象だけを参照しているシステムが最も柔軟である。