Clean Architecture オブジェクト指向プログラミング

• カプセル化

• 継承

• ポリモーフィズム

カプセル化

 「データ(状態)」と「そのデータを操作するメソッド(振る舞い)」を一つの単位(クラス)にまとめて、外部から不必要にアクセスできないようにする仕組み。

継承

 継承は、既存のクラス(親クラス・スーパークラス)から、その機能や性質を引き継いだ新しいクラス(子クラス・サブクラス)を作る仕組み。

ポリモーフィズム

 ポリモーフィズムは、同じメソッド名でも、異なる動作を実行できる性質のこと。

依存関係逆転

 「上位モジュール(ビジネスロジック)が下位モジュール(詳細実装)に依存するのではなく、 どちらも抽象(インターフェース)に依存すべきである」という原則。

依存関係逆転

 モジュールHL1がモジュールML1にあるF()関数を呼び出している。インターフェイス経由で関数を呼び出しているところが、ソースコードの仕掛け。実行時には、インターフェイスには存在しない。HL1はML1にあるF()を呼び出すだけ。

 ML1とインターフェイスIのソースコードの依存関係(継承関係)が、制御の流れと逆転していることに注目。これは依存関係逆転と呼ばれ、ソフトウェアアーキテクトに大きな影響を与えるもの。

 オブジェクト指向言語が安全で便利なポリモーフィズムを提供しているというのは、ソースコードの依存関係は(たとえどこにあっても)逆転できる事を意味する。

 このアプローチを使用することで、オブジェクト指向で書かれたシステムに取り組んでいるソフトウェアアーキテクトは、システムにあるすべてのソースコードの依存関係の方向を絶対的に制御可能。依存関係を制御の流れに合わせる必要はない。どのモジュールが呼び出しを行い、どのモジュールが呼び出されようとも、ソフトウェアアーキテクトはソースコードの依存関係をどの方向にも向けることができる。

 システムのソースコードの依存関係を並び替えるだけで、他の方法を使わなくても、データベースとユーザーインターフェイス(UI)をビジネスルールに依存させることが可能。

データベースとユーザーインターフェイスはビジネスルールに依存

 UIとデータベースをビジネスルールのプラグインにできる。ビジネスルールのソースコードからUIやデータベースに言及することはない。

 結果として、ソースコードと同じ依存関係のまま、ビジネスルール、UI、データベースを3つの異なるコンポーネントやデプロイメントユニットにまとめることが可能。ビジネスルールを含むコンポーネントは、UIやデータベースを含むコンポーネントに依存しない。

 ビジネスルールは、UIやデータベースとは独立してデプロイ可能。UIやデータベースに対する変更が、ビジネスルールに影響を与えることはない。これらのコンポーネントはビジネスルールとは関係なく、独立してデプロイできるため。

独立デプロイ可能性

 コンポーネントのソースコードを変更しても、そのコンポーネントだけ再デプロイすればいい。

独立開発可能性

 システムにあるモジュールを個別にデプロイできるなら、別々のチームが個別に開発可能。

まとめ

 オブジェクト指向とは、「ポリモーフィズムを使用することで、システムにあるすべてのソースコードの依存関係を絶対的に制御する能力」。

 これにより、アーキテクトは「プラグインアーキテクチャ」を作成可能。これは、上位レベルの方針を含んだモジュールを下位レベルの詳細を含んだモジュールから独立させること。下位レベルの詳細はプラグインモジュールとなり、上位レベルの方針を含んだモジュールとは独立して、デプロイおよび開発することが可能。