絵だけで分かった気になるオブジェクト指向プログラミングの成長


雰囲気オブジェクト指向プログラミングシリーズです。

オブジェクト指向プログラミングの成長は、コードの変化もさることながら、コードへの認識が変わることも重要に感じています。そこで、認識の変化を分かりやすくするため、あえてコードなしで、絵だけで視覚化して、成長段階を説明してみたいと思います。

この過程はあくまでも私の経験ベースによるものなので人によっては違うかもしれません。

## 1. 継承


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/f234e0d9-39a7-b460-0deb-b9b8b6884de4.png)

|  |  |
|---|---|
|  `#4472c4`   | 親  |
|  `#ed7d31`  | 拡張  |

継承を覚えた瞬間のイメージですね。
クラスに何かを加えてクラスを大きくしてるイメージです。

# 2. 処理を分割しただけの委譲


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/0dc5e507-da9d-3c38-ac54-e890816a5f49.png)

|  |  |
|---|---|
|  `#5b9bd5`  | 処理全体  |
|  `#ed7d31`  | 処理の一部を委譲したクラス  |

大きな処理の一部を、クラスに切り出してるだけですね。切り出したクラスも含めて処理全体と認識してる段階です。
「継承よりも委譲がいい」と言われてコードを見ても、それが当たり前に見えて良くわからない。
委譲というイメージが湧いていません。

## 3. 処理を分割しただけ ver Web MVC

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/9721a94a-912f-eaa6-a4fa-bbc0c62468d3.png)

|  |  |
|---|---|
|  `#5b9bd5`  | Controller |
|  `#ed7d31`  | Service的なモノ  |
|  `#ffc000`  | DB(ORM) |


責務的なイメージが最初に沸いたのは、レイヤー構造だったので、馴染みのあるWeb MVCとしてみました。
Controllerという処理をただ分割していました。


## 3. オブジェクトの役割(責務)に気付く

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/eda54ada-8b09-bb4b-083a-b02c816bcb15.png)

|  |  |
|---|---|
|  `#4472c4`  | Controller |
|  `#ed7d31`  | Service  |
|  `#ffc000`  | DB(ORM) |

Controllerの役割から、オブジェクトの役割に気付き始めます。

**コードへの認識が大きく変わります！**

* Controllerは、Hogeサービスに、処理を依頼する。
* Controllerは、Hogeサービスの結果によって、プログラムの流れをハンドリグする。
* Hogeサービスは、その処理を実行する実際のサービス。

みたいな感じです。

## 3. 2. オブジェクトの役割に気付いたけど、レイヤ汚染

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/9bcc90d7-9999-ff5b-7bc1-dcb658d76b07.png)

|  |  |
|---|---|
|  `#4472c4`  | Controller |
|  `#ed7d31`  | Service  |
|  `#ffc000`  | DB(ORM) |

少し脱線。レイヤー構造の役割に気付くことで、レイヤーの違反が気になるようになります。

* FormオブジェクトをServiceに渡してしまう。
* SessionオブジェクトをServiceに渡してしまう。

悩みましたが、腑に落ちる方法で解決出来るようになったのは、かなり後でした。
良い解決策をお探しの方は「クリーンアーキテクチャ」等を読むと良いかもしれません。


## 4. 共通化のせいで"処理で分割"に戻る

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/f61f6321-62f8-0336-7285-79dd7d56d99e.png)

|  |  |
|---|---|
|  `#4472c4`  | Controller |
|  `#ed7d31`  | 個別っぽいSevice  |
|  `#5b9bd5`  | 共通Service|
|  `#ffc000`  | DB(ORM) |

処理の**共通化**を強く考えはじめます。

SOLID原則等も何となく知り、「単一の責務」は分かるのですが、ピンと来ません。
共通処理という一つの責務？みたいに、まとめてしまうコードになりました。

## 5. InterfaceでDIしたけど何の意味があるかわからない

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/4ea94830-20b8-c4d7-5fde-bd512e765bab.png)

|  |  |
|---|---|
|  `#4472c4`  | Controller |
|  `#ed7d31`  | 個別っぽいSevice  |
|  `#70ad47`  | Interface  |
|  `#5b9bd5`  | 共通ServiceImpl|
|  `#ffc000`  | DB(ORM) |

DIを知ったきっかけで、Interfaceを利用し始めます。
実装クラスの前に無駄にメソッドだけが定義されたクラスが挟まる。というイメージしか持てません。

テストのし易さで無理やり納得してました。

## 6. Interfaceも相互作用のオブジェクトだと認識する

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/3e9c00d2-e106-99d9-e48a-264bbd2d8625.png)

|  |  |
|---|---|
|  `#4472c4`  | Controller |
|  `#ed7d31`  | 個別っぽいSevice  |
|  `#70ad47`  | Interface  |
|  `#5b9bd5`  | 共通ServiceImpl|
|  `#ffc000`  | DB(ORM) |

利用側の視点が持てると、Interfaceもオブジェクトの一つだと認識できるようになります。

**コードへの認識が大きく変わります！**

ドメイン駆動設計の「Repository」の典型的なDIPパターンでイメージを掴む方も多いですかね。
私は「インタフェース指向設計」というマイナーで少し古い本で理解しました。

## 7. 全体の流れを意識出来ようになる

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/28642348-ff04-e2b3-e8db-7681fc446f6b.png)

|  |  |
|---|---|
|  `#ed7d31`  | UseCase |
|  `#70ad47`  | 共通デカいInterface  |
|  `#AACCCC`  | 流れとして再認識してみる|
|  `#fbe5d6`  | 処理の流れを組む様々なオブジェクト群が必要|

絵はふわっとしてるので、次も一緒に見たいほうがいいかも。

ユースケースシナリオ等の要求仕様や、処理の全体の流れを意識したコードになります。
全体の流れを意識しつつ、オブジェクトを組み合わせていくというイメージが持ち始めます。
このイメージがあると、共通処理でまとめて無理やり分割してたことが、クラスの歪みの原因だと気づきます。

オブジェクト指向分析/設計系の知識も必要になります。まんまの「ユースケース駆動開発実践ガイド」がお勧めです。「オブジェクトデザイン」のステレオタイプもおすすめです。

## 8. 責務を意識したクラス分解(オブジェクト指向設計)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/9924adba-a2c3-2bee-44f0-5f781dd25178.png)

|  |  |
|---|---|
|  `#ed7d31`  | UseCase   |
|  `#fbe5d6`  | 処理の流れを組む様々なオブジェクト群が必要|
|  `#70ad47`  | Interfaceを利用したオブジェクト  |
|  `#5b9bd5`  | 独立した小さなオブジェクト  |
|  `#a260bf`  | 本当に必要だった共通オブジェクト  |

オブジェクトの責務を意識した「小さく独立したクラスの重要性」のイメージを持つと、オブジェクトを組み合わせつつ全体の流れを作るという設計ができるようになります。

表現のためにクラス構造を変えるという手法も必要になり、DIPやポリモーフィズム等のオブジェクト指向設計を自然に活用したクラス分割が始まります。前段階の7に至る時点で、実はこのイメージも必要な気がします。

## 8. 2. 並び変えただけ

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/020975df-b798-ed19-57ef-84970f5e69d5.png)

|  |  |
|---|---|
|  `#ed7d31`  | UseCase   |
|  `#CCAd81`  | 処理の流れを叶えるための様々なオブジェクト群 |
|  `#70ad47`  | Interfaceを利用したオブジェクト  |
|  `#5b9bd5`  | 独立した小さなオブジェクト  |
|  `#a260bf`  | 本当に必要だった共通オブジェクト  |

流れっぽく並べ替えただけです。

## 9. Web MVCを再統合して

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/56358dc8-cadf-9313-551c-6532dc84daea.png)

|  |  |
|---|---|
|  `#4472c4`  | Controller |
|  `#ed7d31`  | UseCase   |
|  `#70ad47`  | Interfaceを利用したオブジェクト  |
|  `#5b9bd5`  | 独立した小さなオブジェクト  |
|  `#a260bf`  | 本当に必要だった共通オブジェクト  |
|  `#ffc000`  | DB(ORM) |

せっかくの絵なのでWeb MVCと統合して、それっぽくしてみました。
このレイヤ分解が正解という意図はなし。

## 10 おまけ 実はコードの構成は変わってない


![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/56358dc8-cadf-9313-551c-6532dc84daea.png)

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/29715/f61fac22-9735-6757-93c5-58e4df4328d8.png)

レイヤ視点でのコード構造的には実は何も変わっていません。
まさに、認識によってコードの見え方が変わっているだけなのです。

## おわり

プログラミングのコードは、ぱっと見で構造的に理解しても、認識の違いによって大きく意図が変わってしまうことが多々あります。デザインパターンなどまさにそれですね。
逆手に取ってフィットアンドギャップに利用したのがドメイン駆動設計だと考えると、それが面白い試みだなと気づかされます。
ただ、この認識の違いこそが、オブジェクト指向プログラミングの学習の難しさに繋がっているのかなと思い付き、記事を書いてみました。

イメージだけにイメージが伝わると幸いです。