SOLID

There should never be more than one reason for a class to change.[6]（→変更するための理由が、一つのクラスに対して一つ以上あってはならない）

これは、every class should have only one responsibility.（→各クラスはそれぞれ一つだけの責務を持つべきである）とも言い換えられる。ここでの責務とは提供機能と同義である。この原則は、clientに特定の機能を提供する役割（role）役者（actor）としてのserviceのクラスに焦点を当てている。

この原則下のserviceは、それぞれ一つの機能または一つの役割しか持てない。この原則下のclientは、機能別に担当serviceを変更することになる。

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.[7]（→ソフトウェアの実体（クラス、モジュール、関数など）は、拡張に対して開かれているべきであり、修正に対して閉じていなければならない）

この原則下のinterfaceはその構成が不変になり、serviceは構成の変化が許される。serviceの構成変化は、継承によるサブクラス定義でなされるのが普通である。

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.[8]（→ある基底クラスへのポインタないし参照を扱っている関数群は、その派生クラスのオブジェクトの詳細を知らなくても扱えるようにしなければならない）

この原則下のclientは、一つのinterfaceを通して、様々なserviceクラスを利用することになる。

Many client-specific interfaces are better than one general-purpose interface.[9]（→汎用なインターフェースが一つあるよりも、各クライアントに特化したインターフェースがたくさんあった方がよい）

この原則下のinterfaceは、様々に機能分化されて細かな用途ごとに定義されることになる。

High-level modules should not import anything from low-level modules. Both should depend on abstractions (e.g., interfaces), [not] concretions.[10]（→上位モジュールはいかなるものも下位モジュールから持ち込んではならない。双方とも具象ではなく、抽象（インターフェースなど）に依存するべきである）

この原則は、Mix-inをモチーフにして依存性の注入などのベースになっている。

この原則下のclientは、専門機能が分離されたモジュールにされる。その下位モジュールは専門機能の扱い方を変えたものにされる。専門機能とは、clientがinterfaceを通して利用するserviceであり、上位clientと下位clientは共に、専門機能interfaceに依存することになる。ここでのclientは具象であり、interfaceは抽象である。