第４回読書会（デザインパターンに学ぶオブジェクト指向のこころ　第６章~第７章）

• appear.inにて参加（参加希望の方はfuruya0102@growth-and.comまでご連絡ください）
• 音声通話の準備（マイクとヘッドホンの準備。ヘッドセットがあれば楽です）
• 課題図書の購入 （オブジェクト指向のこころ）
• 範囲の理解

1. 全員が事前に範囲を読んでおく（この時、わからない点や思ったことをメモっておくと良い）
2. 説明役を一人決め、その説明役が当日説明をする
3. 次の日時、範囲、説明役（及び説明代理）を決める
4. ブログに参加者、範囲、レビュー等の情報を掲載

今回の読書会範囲

1. 第６章　Facadeパターン
2. 第７章　Adapterパターン

読書会参加者

• 古家（グロースアンドコミュニケーションズ株式会社）
• 玉尾（グロースアンドコミュニケーションズ株式会社）
• 井上（ライジングサン企画株式会社）

今回の感想

今回は説明者は古家がやりました。
この章から本格的にデザインパターンを紹介していく流れです。
今までの前振りも重要ではありますがデザインパターンの森を見て木を見ていない状態でふわっとした感覚だけが漂っている感じでした。
今回からは一つ一つのデザインパターンにフォーカスを当てて、現実に存在し得る厄介な問題と、その解決策に関して述べていくスタイルとなっていきます。
パターンの特徴や構造を述べられている箇所に付せんでも貼っておくと後でリファレンス的な使い方も出来るようになるのではないでしょうか。

第６章　Facadeパターン

玄関の正面とか、見せかけという意味のパターンです。
詳細な仕様を忠実に再現しなければいけないクラスライブラリなどがあった際に、そういうものを全員が共有しなければいけない状態であると属人化（その仕様を詳細に理解している人しか触れない）してしまったり、全員が専門家にならないと開発を共有出来ません。
しかし、そういうものを隠ぺいしてしまい、メンテナンスを一人に任せることで、具体的な手順や不要な処理を考えることなくアクセスできるようになる。といったものです。
ファサード経由のメソッドにすべて任せてしまえばそのファサードにはログ採取や速度解析などの付加価値を入れることだってできます。
例えば、データベースにアクセスする際にエンティティやデータベースのコネクションなどを全員が理解するよりもDatabaseFacadeを作って、そこにアクセスを一任してしまう等の使い方があります。
本書ではDatabaseFacadeという名前でしたが、こういうのはリポジトリパターンとも呼ばれますね。リポジトリパターンは抽象化レイヤを置きますが、ファサードは置かなくてもよいという違いこそありますが。

ちなみに７章Adapterにもいえることで、本書には載っていない暗黙の指針ですが、インターフェイスを置く際にはStairway（階段）パターンとEntourage（取り巻き）アンチパターンにも注意しましょう。
折角インターフェイスで分離したというのに、その実装をインターフェイスと同じアセンブリで持ってしまっていると、取り巻きのようにくっついてきてしまいます。そういうものは別アセンブリに定義していつでも切り離せるような作りにしておくことで依存関係を効率的にコントロールできます。

第７章　Adapterパターン

Facadeパターンと対比させて述べられているパターンです。Facadeとよく似ていますが、Facadeは複雑な手順や不要な処理を隠ぺいする目的で、別にインターフェイスである必要もありませんが、Adapterパターンは合致しないインターフェイスを適合させる意味で用います。
Adapterには2種類あり、ObjectをコンポジションしてしまうObjectAdapterとクラス継承を用いるClassAdapterがあります。
どちらも一長一短ではありますが、個人的な感覚としては基本的にはObjectAdapterを使い、protectedメソッドやvirtualメソッドなどでカスタマイズする必要性が出てきたらClassAdapterに切り替える的な使い方をする気がします。

次回について

次回は6月26日になります。対象範囲は８章の視野を広げると９章のStrategyパターンで説明を井上さんに行っていただく予定です。